gr-mcp-docs/reference/cospas-sarsat/g-series/g010.md

---
title: "G010: C/S G.010 Issue 1 - Rev.3"
description: "Official Cospas-Sarsat G-series document G010"
sidebar:
  badge:
    text: "G"
    variant: "note"
# Extended Cospas-Sarsat metadata
documentId: "G010"
series: "G"
seriesName: "General"
documentType: "overview"
isLatest: true
issue: 1
revision: 3
documentDate: "October 2024"
originalTitle: "C/S G.010 Issue 1 - Rev.3"
---

> **📋 Document Information**
>
> **Series:** G-Series (General)
> **Version:** Issue 1 - Revision 3
> **Date:** October 2024
> **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents)

---

MCC HANDBOOK
C/S G.010
Issue 1 – Revision 3

![Image 1 from page 1](/images/cospas-sarsat/G-series/G010/G010_page_1_img_1.png)


MCC HANDBOOK
HISTORY
Issue
Revision Date
Comments


Approved by CSC-64


Approved by CSC-66


Approved by CSC-69


Approved by CSC-71


TABLE OF CONTENTS
Page
History.............................................................................................................................................. i
Table of Contents ............................................................................................................................ ii
List of Annexes  .............................................................................................................................. v
List of Figures ................................................................................................................................. x
List of Tables .................................................................................................................................. x
1.
INTRODUCTION ....................................................................................................... 1-1
1.1
Purpose ....................................................................................................................... 1-1
1.2
Scope ........................................................................................................................... 1-2
1.3
Document Organization ............................................................................................ 1-2
2.
THE COSPAS-SARSAT PROGRAMME ................................................................ 2-1
2.1
General ....................................................................................................................... 2-1
2.2
History ........................................................................................................................ 2-1
2.2.1
Stakeholder Organizations ................................................................................. 2-4
2.3
Cospas-Sarsat Website .............................................................................................. 2-9
2.4
Cospas-Sarsat Reference Documents .................................................................... 2-11
2.4.1
General Reference Documents ........................................................................ 2-11
2.4.2
Programme Documents .................................................................................... 2-12
2.4.3
Operational Documents ................................................................................... 2-13
2.4.4
Technical Documents....................................................................................... 2-13
2.4.5
IBRD Documents ............................................................................................. 2-14
2.4.6
Cospas-Sarsat Videos....................................................................................... 2-14
3.
OVERVIEW OF THE COSPAS-SARSAT SYSTEM ............................................. 3-1
3.1
Mission Statement ..................................................................................................... 3-1
3.2
Introduction ............................................................................................................... 3-1
3.3
Beacon Segment ......................................................................................................... 3-2
3.4
Space Segment ........................................................................................................... 3-5
3.5
Ground Segment ........................................................................................................ 3-8
4.
THE MISSION CONTROL CENTRE ...................................................................... 4-1
4.1
Overview..................................................................................................................... 4-1
4.1.1
Functions of an MCC ......................................................................................... 4-1


4.1.2
Operational Requirements ................................................................................. 4-2
4.1.3
Location and Facilities ....................................................................................... 4-4
4.1.4
Management and Personnel ............................................................................... 4-4
4.1.5
MCC Equipment ................................................................................................ 4-5
4.1.6
Automatic Operations ........................................................................................ 4-7
4.2
Processing LUT Data ................................................................................................ 4-9
4.3
Cospas-Sarsat Data Distribution Plan ..................................................................... 4-9
4.3.1
MCC Service Area ............................................................................................. 4-9
4.3.2
DDRs and Nodal MCCs................................................................................... 4-10
4.3.3
RCCs, SPOCs and Search and Rescue Regions .............................................. 4-12
4.3.4
Alert Data Distribution .................................................................................... 4-15
4.3.5
System Data Distribution ................................................................................. 4-19
4.4
Data Communication .............................................................................................. 4-22
4.4.1
Communication Links ...................................................................................... 4-24
4.4.2
Interfaces .......................................................................................................... 4-26
4.5
SIT Messages............................................................................................................ 4-29
4.5.1
Introduction ...................................................................................................... 4-29
4.5.2
MCC to MCC Incident Alert Messages ........................................................... 4-30
4.5.3
MCC to RCC/SPOC Messages ........................................................................ 4-30
4.5.4
System Information .......................................................................................... 4-30
4.5.5
Narrative Messages .......................................................................................... 4-30
4.6
Quality Management System ................................................................................. 4-30
4.6.1
QMS Evaluation............................................................................................... 4-31
4.6.2
MCC Roles in QMS ......................................................................................... 4-32
5.
MCC OPERATIONS .................................................................................................. 5-1
5.1
Management............................................................................................................... 5-1
5.1.1
Staffing ............................................................................................................... 5-2
5.1.2
Training .............................................................................................................. 5-2
5.1.3
Voice Communications ...................................................................................... 5-3
5.1.4
Language ............................................................................................................ 5-3
5.2
Daily Operations ........................................................................................................ 5-4
5.2.1
Activities for MCC System Manager ................................................................ 5-5
5.2.2
Activities for MCC Operator ............................................................................. 5-7
5.2.3
Monitoring the Operation of MCC .................................................................... 5-8
5.2.4
Test Procedures .................................................................................................. 5-9
5.2.5
MCC Operational Backup................................................................................ 5-11
5.3
Monitoring and Test Activities ............................................................................... 5-12
5.3.1
MCC Commissioning ...................................................................................... 5-12
5.3.2
Monitoring the National Ground Segment ...................................................... 5-16
5.3.3
Communications Link Monitoring .................................................................. 5-17


5.3.4
Space Segment Monitoring .............................................................................. 5-22
6.
FUNCTIONS OF AN MCC OPERATOR ................................................................ 6-1
6.1
Communications with SPOCs .................................................................................. 6-1
6.2
Communications with other MCCs ......................................................................... 6-3
6.2.1
General Communications................................................................................... 6-3
6.2.2
Narrative Messages ............................................................................................ 6-4
6.2.3
System Status Messages .................................................................................... 6-5
6.2.4
SIT Messages Embedded in Narrative Messages .............................................. 6-5
6.3
Monitoring the System .............................................................................................. 6-6
6.3.1
External Systems Monitoring ............................................................................ 6-6
6.3.2
Reference Beacon Monitoring ........................................................................... 6-7
6.4
MCC Backups ............................................................................................................ 6-7
6.5
Communications Support ......................................................................................... 6-8
6.6
Resending a Missing Message ................................................................................ 6-10
6.7
Suppressing Beacon Alerts ..................................................................................... 6-12
6.8
Quality Management System Messages ................................................................ 6-15
6.9
Beacon Registration Requests ................................................................................ 6-17
6.10
System Data Updates............................................................................................... 6-21
6.10.1
LEOSAR Orbital Elements .............................................................................. 6-22
6.10.2
MEOSAR Orbital Elements ............................................................................. 6-23
6.10.3
GEOSAR Orbital Elements ............................................................................. 6-24
6.10.4
LEOSAR SARP Calibration ............................................................................ 6-24
6.10.5
LEOSAR SARR Calibration............................................................................ 6-25
6.10.6
MEOSAR SARR Calibration .......................................................................... 6-26
6.10.7
GEOSAR SARR Calibration ........................................................................... 6-27
6.11
Satellite Manoeuvres ............................................................................................... 6-27
6.12
Satellite Outages ...................................................................................................... 6-30
6.13
Coverage Analysis ................................................................................................... 6-31
6.13.1
LEOSAR Coverage .......................................................................................... 6-31
6.13.2
MEOSAR Coverage......................................................................................... 6-32
6.13.3
GEOSAR Coverage ......................................................................................... 6-32
6.14
Beacon Testing ......................................................................................................... 6-32
6.14.1
Beacon Self-Test Messages ............................................................................. 6-33
6.14.2
Test Beacons and Beacon Simulators .............................................................. 6-33
6.14.3
Notification of a Planned Beacon Test ............................................................ 6-34
6.14.4
Processing Data from a Beacon Test ............................................................... 6-36
6.14.5
System-Wide Tests .......................................................................................... 6-36


ANNEXES
ANNEX A : DATA DISTRIBUTION ..................................................................................... A-1
A.1
Nodal Data Distribution Network ........................................................................... A-1
A.1.1
Special Rules ..................................................................................................... A-2
A.1.2
Cospas-Sarsat GEOSORT ................................................................................ A-2
A.1.2.1
Data Distribution Regions ............................................................................ A-2
A.1.3
MCC Service Areas .......................................................................................... A-3
A.1.4
Message Formatting .......................................................................................... A-3
A.1.5
Alert Message Validation ................................................................................. A-3
A.2
Alert Data Distribution ............................................................................................ A-4
A.3
DDP Processing Matrices ........................................................................................ A-4
A.4
Alert Types ................................................................................................................ A-8
A.4.1
Unlocated Alerts ............................................................................................... A-8
A.4.2
Alerts with Beacon Position Estimates ............................................................. A-8
A.4.2.1
Position Data ................................................................................................ A-9
A.4.3
Confirmed Beacon Alerts ................................................................................. A-9
A.4.3.1
Matching and Merging of Beacons ............................................................ A-10
A.4.3.2
Beacon Confirmation ................................................................................. A-10
A.4.3.3
Position Confirmation ................................................................................ A-10
A.4.3.4
Distribution of Confirmed Solutions .......................................................... A-10
A.4.3.5
Conflict Solutions ....................................................................................... A-11
A.4.4
Alert Message Contents .................................................................................. A-11
A.4.5
Alert Message Routing ................................................................................... A-12
A.4.6
Continued Transmission ................................................................................. A-13
A.4.7
Special Processing .......................................................................................... A-13
A.4.7.1
Ship Security Alert ..................................................................................... A-14
A.4.7.2
Return Link Service Alert .......................................................................... A-14
A.4.7.3
Distress Tracking ELT Alert ...................................................................... A-16
A.4.7.4
System Beacons ......................................................................................... A-18
A.4.7.5
Notification of Country of Registration Alert ............................................ A-21
A.4.7.6
Cancellation Message ................................................................................. A-22
A.5
Message Transmission ........................................................................................... A-23
A.6
Data Validation ....................................................................................................... A-23
A.6.1
406 MHz Alert Message Validation ............................................................... A-23
A.6.2
Concept of Filtering Redundant Data and Better-Quality Alerts .................... A-26
A.6.3
Event Flags...................................................................................................... A-26
A.6.4
Distance Criteria ............................................................................................. A-27
A.6.5
Image Position Determination ........................................................................ A-29
A.6.6
Satellite Footprint Verification ....................................................................... A-29
A.6.7
Bit Errors ......................................................................................................... A-29


A.6.7.1
Satellite Link Errors ................................................................................... A-30
A.6.7.2
LUT to MCC Errors ................................................................................... A-30
A.6.7.3
MCC to MCC Errors .................................................................................. A-31
A.6.7.4
MCC to RCC Errors ................................................................................... A-31
A.6.7.5
MCC Bit Error Processing ......................................................................... A-31
A.7
System Data Distribution ....................................................................................... A-31
A.7.1
System Data SIT Message Formats ................................................................ A-32
A.7.2
Satellite Orbit Messages ................................................................................. A-33
A.7.2.1
Position and Velocity Vectors .................................................................... A-33
A.7.2.2
NORAD Two-Line Elements ..................................................................... A-34
A.7.2.3
Orbit Reference Coordinate System ........................................................... A-34
A.7.3
System Calibration .......................................................................................... A-34
A.7.3.1
SARP Calibration ....................................................................................... A-34
A.7.3.2
SARR Calibration ...................................................................................... A-35
A.7.4
Spacecraft Instrument Control Messages........................................................ A-35
A.7.5
System Status and Narrative Messages........................................................... A-35
A.7.5.1
System Status ............................................................................................. A-36
A.7.5.2
Narrative Messages .................................................................................... A-36
A.7.6
Beacon Registration Data ............................................................................... A-36
ANNEX B : DESCRIPTION OF SIT MESSAGES ............................................................... B-1
B.1
International Character Set .................................................................................... B-1
B.2
Message Subject Indicator Types ........................................................................... B-2
B.3
Message Fields .......................................................................................................... B-4
B.3.1
Message Field Identification ............................................................................. B-5
B.3.2
Message Field Descriptions .............................................................................. B-5
B.4
Lists of Message Fields ............................................................................................. B-6
B.4.1
Control Fields.................................................................................................... B-6
B.4.2
Beacon Identification and Beacon Message ..................................................... B-8
B.4.3
Solution Data .................................................................................................... B-8
B.4.3.1 Spacecraft Identification ................................................................................. B-10
B.4.3.2 Orbit Number .................................................................................................. B-11
B.4.3.3 Source Identifier.............................................................................................. B-11
B.4.3.4 Frequency Band .............................................................................................. B-11
B.4.3.5 Solution Frequency ......................................................................................... B-11
B.4.3.6 Time ................................................................................................................ B-12
B.4.3.7 Number of Points or Bursts............................................................................. B-12
B.4.4
Solution Quality Data ..................................................................................... B-12
B.4.5
Message Fields for SIT 185 Messages............................................................ B-13
B.5
Incident Alert Messages ......................................................................................... B-13
B.5.1
Unlocated Alerts ............................................................................................. B-14
B.5.2
Encoded Location Alert .................................................................................. B-14


B.5.3
Independent Location Alert ............................................................................ B-14
B.5.3.1 Doppler Location Alert ................................................................................... B-15
B.5.3.2 Difference of Arrival Location Alert .............................................................. B-16
B.5.4
Special Message Formats ................................................................................ B-16
B.5.5
Unconfirmed Location Alert ........................................................................... B-17
B.5.6
Confirmed Location Alert ............................................................................... B-17
B.5.7
Conflict Solution Alert .................................................................................... B-17
B.5.8
Notification of Country of Registry ................................................................ B-18
B.5.9
Ship Security Alerting System Alert............................................................... B-18
B.5.10
Aircraft Distress Tracking Alert ..................................................................... B-18
B.5.11
Return Link System Notification .................................................................... B-18
B.5.12
Interferer Alerts ............................................................................................... B-18
B.5.12.1 Number of Sidebands ................................................................................. B-19
B.5.12.2 Sweep Period and Standard Deviation ....................................................... B-19
B.6
System Information ................................................................................................ B-19
B.6.1
Orbital Elements ............................................................................................. B-19
B.6.1.1 SIT 215 Message Format (Orbit Vectors) ...................................................... B-20
B.6.1.2 SIT 216 Message Format (Orbit Vectors) ...................................................... B-20
B.6.1.3 SIT 217 Message Format (Two-Line Elements) ............................................ B-20
B.6.2
LEOSAR SARP Calibration ........................................................................... B-21
B.6.3
LEOSAR SARR Calibration........................................................................... B-21
B.6.4
Satellite Command and Control Messages ..................................................... B-22
B.6.5
System Status .................................................................................................. B-23
B.6.5.1 SIT 605............................................................................................................ B-23
B.7
Narrative Messages ................................................................................................ B-24
B.7.1
Narrative Message Text .................................................................................. B-24
B.7.2
SIT 915 (Simple Narrative Message) ............................................................. B-24
B.7.3
SIT 925 (406 MHz Beacon Information with 15-Hex ID) ............................. B-25
B.7.4
SIT 926 (406 MHz Beacon Information with 23-Hex ID) ............................. B-25
B.7.5
SIT 927 (SGB Type Approval Information for MCCs) ................................. B-25
B.7.6
SIT 985 (SGB Type Approval Information for SPOCs and RCCs) ............... B-25
B.8
Operational Message Templates ........................................................................... B-26
B.8.1
SIT 605 – MCC Backup ................................................................................. B-26
B.8.2
SIT 605 – MCC Resuming Operations after the Backup ............................... B-29
B.8.3
SIT 915 – Beacon Test Coordination.............................................................. B-30
B.8.4
SIT 915 – Cospas-Sarsat Alert Results ........................................................... B-31
B.8.5
Filtering Doppler Position............................................................................... B-34
B.9
QMS Related Messages .......................................................................................... B-38
B.9.1
LEOLUT/LEOSAT Availability Status .......................................................... B-39
B.9.2
LEOLUT/LEOSAT Location Accuracy Status .............................................. B-40
B.9.3
GEOLUT/GEOSAT Low Availability ........................................................... B-42
B.9.4
MEOLUT Location Accuracy Status Messages ............................................. B-44
B.9.5
MEOLUT Detection Probability Status Messages ......................................... B-46


B.9.6
MEOLUT Location Probability Status Messages........................................... B-46
B.9.7
MEOLUT Local Antenna Availability Status Messages ................................ B-48
B.9.8
MEOLUT Timeliness Status Messages .......................................................... B-48
ANNEX C : LOCATION DATA CONCEPTS AND TERMINOLOGY ............................ C-1
C.1
LEOSAR Doppler Solution Processing ............................................................ C-1
C.1.1.1 Doppler Curve ................................................................................................... C-1
C.1.2
A and B Positions.............................................................................................. C-2
C.1.2.1 LEOSAR Ambiguity Resolution ...................................................................... C-2
C.1.3
Time of Closest Approach (TCA)..................................................................... C-4
C.1.4
Cross-Track Angle (CTA) ................................................................................ C-4
C.1.5
Number of Points .............................................................................................. C-4
C.1.6
Window Factor.................................................................................................. C-5
C.1.7
Theoretical Number of Points for a Particular Satellite and CTA .................... C-7
C.1.8
Next Time of Visibility ..................................................................................... C-8
C.2
MEOSAR Difference of Arrival (DOA) Solution Processing ............................... C-8
C.2.1
Multilateration................................................................................................... C-8
C.2.2
Single Burst Solution ........................................................................................ C-9
C.2.3
Multi-Burst Solution ......................................................................................... C-9
C.2.4
MEOLUT Configuration ................................................................................ C-10
C.2.4.1 Networked Antennas ....................................................................................... C-10
C.2.5
MEOSAR Quality Assessment ....................................................................... C-11
C.2.6
Uncorroborated Alerts .................................................................................... C-11
C.3
Two-Line (Orbital) Elements (TLE)..................................................................... C-12
C.4
Moving Beacons ...................................................................................................... C-12
C.5
Independent Location Accuracy Estimates ......................................................... C-13
C.5.1
LEOSAR Error Ellipse ................................................................................... C-13
C.5.2
MEOSAR Expected Horizontal Error ............................................................ C-14
C.5.3
Confidence Factor (CF) .................................................................................. C-16
C.6
Large Location Errors and Possible Causes ........................................................ C-16
C.6.1
Encoded Location Data ................................................................................... C-17
C.6.2
Doppler Location Data .................................................................................... C-19
C.6.3
DOA Location Data ........................................................................................ C-20
ANNEX D : CONTINGENCY PROCEDURES .................................................................... D-1
D.1
Operational Backup ................................................................................................. D-1
D.1.1
Internal Back-up MCC ...................................................................................... D-2
D.1.2
Backup Another MCC ...................................................................................... D-2
D.1.3
Long Term Backup ........................................................................................... D-2
D.1.4
Backup in the Same DDR ................................................................................. D-3
D.1.4.1
Nodal MCC Backup ..................................................................................... D-4
D.1.4.2
Non-Nodal MCC Backup ............................................................................. D-4


D.1.5
Summary of Actions for MCC Scheduled and Contingency/Operational Backup
D-6
D.2
LUT Data to Non-parent MCC ............................................................................... D-7
D.3
Use of Email for Transfer of SIT Messages ........................................................... D-8
D.4
Re-routing Alert Data between MCCs ................................................................... D-8
D.5
Special Procedures for the Transitional Phase-only ............................................. D-8
D.5.1
Encapsulation Procedure ................................................................................. D-10
D.5.2
Distribution of MEOSAR Alerts to LG MCCs............................................... D-10
D.5.3
Distribution of Second-Generation Beacon Alerts to FGB-Only MCCs........ D-11
D.5.4
Distribution of FGB-ELT(DT) Alerts to Non-FGB-ELT(DT) MCCs ........... D-11
D.5.5
Distribution of Alerts for RLS-Capable FGBs to Non-FGB-RLS MCCs ...... D-12
D.5.6
Distribution of RLSP Notifications ................................................................ D-12
D.5.7
Operational Distribution of Alert Data for SGBs and FGB ELT(DT)s .......... D-13
ANNEX E : SPECIALIZED REQUIREMENTS .................................................................. E-1
E.1
Nodal MCC ............................................................................................................... E-1
E.1.1
Requirements ..................................................................................................... E-1
E.1.2
Operations .......................................................................................................... E-1
E.2
Reference Beacon Provider ..................................................................................... E-2
E.3
Beacon Registry ........................................................................................................ E-3
E.4
Space Segment Provider .......................................................................................... E-3
E.5
Return Link Service Provider ................................................................................. E-5
E.5.1
SAR/Galileo RLS............................................................................................... E-6
ANNEX F : MONITORING AND TEST ACTIVITIES ....................................................... F-1
F.1
Commissioning Support............................................................................................ F-1
F.1.1
MCC Commissioning ........................................................................................ F-1
F.1.2
LUT Commissioning ......................................................................................... F-2
F.1.2.1 Notifying a LUT to ITU ..................................................................................... F-4
F.1.3
Space Segment Commissioning ......................................................................... F-4
F.2
MCC Annual Backup Test ....................................................................................... F-5
F.3
Monthly Communication Link Testing with SPOCs ............................................. F-6
F.4
Beacon Type Approval Tests .................................................................................... F-6
F.5
Interference Monitoring ........................................................................................... F-7
F.5.1
In-Band Interference .......................................................................................... F-7
F.5.2
Out-Of-Band Interference .................................................................................. F-8
ANNEX G : COSPAS-SARSAT MODEL COURSE ............................................................ G-1
G.1
Purpose of the Model Course .................................................................................. G-1


G.2
Training Resources................................................................................................... G-1
G.3
Detailed Outline ........................................................................................................ G-2
G.3.1
Concept of the Cospas-Sarsat System: ............................................................. G-2
G.3.2
Management of the Cospas-Sarsat Programme: ............................................... G-2
G.3.3
Space Segment (LEO, GEO and MEO):........................................................... G-3
G.3.4
Ground Segment: .............................................................................................. G-3
G.3.5
LUTs: ................................................................................................................ G-3
G.3.6
MCCs: ............................................................................................................... G-4
G.3.7
Cospas-Sarsat Data Distribution Procedures: ................................................... G-4
G.3.8
Cospas-Sarsat Message Formats: ...................................................................... G-5
G.3.9
Beacons: ............................................................................................................ G-6
G.3.10
Communications: .............................................................................................. G-7
G.3.11
Contingency Procedures: .................................................................................. G-8
G.3.12
Documentation Set: ........................................................................................... G-8
G.3.13
Competency Check: .......................................................................................... G-8
G.3.14
On-the-Job Training: ......................................................................................... G-8
G.3.14.1 Working Time Schedule: ............................................................................. G-9
G.3.14.2 Training Plan (subject to be covered): ......................................................... G-9
G.3.14.3 MCC Operator Checkout and Certification: .............................................. G-10
G.3.14.4 Recurrent Training/Recertification ............................................................ G-10


LIST OF FIGURES
Figure 3.1: Flow of control .......................................................................................................... 3-2
Figure 3.2: Types of Cospas-Sarsat Distress Beacon .................................................................. 3-3
Figure 3.3: Cospas-Sarsat Distress Beacons ................................................................................ 3-4
Figure 3.4: Cospas-Sarsat Satellite Visibility .............................................................................. 3-7
Figure 4.1: Cospas-Sarsat Concept of Operations ....................................................................... 4-1
Figure 4.2: Typical Cospas-Sarsat MCC Functional Block Diagram.......................................... 4-2
Figure 4.3: Typical MCC Images ................................................................................................ 4-6
Figure 4.4: Cospas-Sarsat Data Distribution Network .............................................................. 4-11
Figure 4.5: IMO GISIS Maritime Security Website Interface ................................................... 4-29
Figure 6.1: Sample Narrative Message ........................................................................................ 6-4
Figure 6.2: Sample System Status Message ................................................................................ 6-5
Figure 6.3: Sample Notification of Communications Failure ...................................................... 6-9
Figure 6.4: Sample Message Re-Transmission Request ............................................................ 6-11
Figure 6.5: Sample Re-Transmitted Message ............................................................................ 6-12
Figure 6.6: Sample Message to Request Suppression of Beacon Alerts ................................... 6-14
Figure 6.7: Sample Message to Confirm Suppression of Beacon Alerts ................................... 6-14
Figure 6.8: Sample QMS Status Display ................................................................................... 6-17
Figure 6.9: Sample Message to Request Beacon Registration Data .......................................... 6-19
Figure 6.10: Sample Message to Report Beacon Registration Data .......................................... 6-20
Figure 6.11: Sample Message to Report No Beacon Registration Data .................................... 6-21
Figure 6.12: Sample Message to Announce a LEOSAR Satellite Manoeuvre .......................... 6-29
Figure 6.13: Sample Message to Announce a Planned Beacon Test Activation ....................... 6-35
Figure A.1: Alert Data Processing Concept ................................................................................ A-5
Figure A.2: Return Link Service ............................................................................................... A-15
Figure A.3: Distress Tracking Alert Support ............................................................................ A-17
Figure A.4: Flow of Cospas-Sarsat QMS Data ......................................................................... A-21
Figure B.1: Sample SIT 605 Announcement of MCC Backup ................................................ B-27
Figure B.2: Sample SIT 605 Announcement of MCC Backup ................................................ B-28
Figure B.3: Sample SIT 605 Announcement of MCC Backup ................................................ B-29
Figure B.4: Sample SIT 605 Announcement of MCC Resuming Operations .......................... B-29


Figure B.5: Sample SIT 605 Announcement of MCC Resuming Operations .......................... B-30
Figure B.6: Sample SIT 915 Notification of a Planned Beacon Test ....................................... B-31
Figure B.7: Sample SIT 915 Notification of a False Alert ....................................................... B-32
Figure B.8: Information Graphic on Sources of False Alerts ................................................... B-32
Figure B.9: Sample SIT 915 Notification of a Real Distress Incident...................................... B-33
Figure B.10: SIT 915 Location Accuracy Warning Message ................................................... B-34
Figure B.11: Sample SIT 605 Announcement of LEOSAR Location Accuracy Problem ....... B-36
Figure B.12: Sample SIT 915 Announcement of Doppler Location Filtering ......................... B-36
Figure B.13: Sample SIT 605 Announcement of LEOLUT/Satellite Conformity Status ........ B-37
Figure B.14: Sample SIT 605 Announcement of the Resumed Distribution of Doppler Solutions
........................................................................................................................... B-37
Figure C.1: A Sample Doppler Curve......................................................................................... C-1
Figure C.2: Unresolved Doppler Match Scenario....................................................................... C-3
Figure C.3: Window Factor Calculation ..................................................................................... C-6
Figure C.4: MEOSAR DOA Location Error ............................................................................ C-15
Figure C.5: Range Limits for DOA Location Error .................................................................. C-15
Figure C.6: DOA Location Error .............................................................................................. C-16


LIST OF TABLES
Table 1-1 – Structure of the MCC Handbook .............................................................................. 1-2
Table 1-2 – Annexes to the MCC Handbook ............................................................................... 1-3
Table 2-1 – Space Segment Agreement Documents.................................................................... 2-3
Table 2-2 – Annexes to the Chicago Convention ........................................................................ 2-6
Table 2-3 – General Information Documents ............................................................................ 2-11
Table 2-4 – Programme Documents .......................................................................................... 2-12
Table 2-5 – Operational Documents .......................................................................................... 2-13
Table 2-6 – Technical Documents ............................................................................................. 2-13
Table 2-7 – IBRD Documents ................................................................................................... 2-14
Table 3-1 – Cospas-Sarsat Beacon Specifications ....................................................................... 3-4
Table 3-2 – Cospas-Sarsat Space Segment .................................................................................. 3-8
Table 4-1 – MCC Software Structure .......................................................................................... 4-7
Table 4-2 – Data Distribution Regions ...................................................................................... 4-10
Table 4-3 – Special Processing .................................................................................................. 4-18
Table 4-4 – System Data ............................................................................................................ 4-19
Table 4-5 – Network Annexes in the SID .................................................................................. 4-23
Table 5-1 – Beacon Type Approval Documents ........................................................................ 5-10
Table 6-1 – Sources of Satellite Orbit Data ............................................................................... 6-22
Table A-1: Subscripts used in Processing Matrices .................................................................... A-5
Table A-2 - Extract from MEOSAR Processing Matrix ............................................................. A-6
Table A-3: Processing Matrix Destination Codes ...................................................................... A-7
Table A-4: Essential Message Fields ........................................................................................ A-24
Table A-5: Solution Match Criteria .......................................................................................... A-28
Table A-6: Better Quality Solution Criteria .............................................................................. A-28
Table A-7: Bit Error Detection and Correction ........................................................................ A-30
Table A-8: System Data ............................................................................................................ A-32
Table B-1: Replacement Character Sequences ........................................................................... B-2
Table B-2: Alert Messages by Beacon Generation ..................................................................... B-2
Table B-3: LEOSAR and GEOSAR Alert Messages ................................................................. B-3
Table B-4: MEOSAR Alert Messages ........................................................................................ B-3


Table B-5: Message Control Fields ............................................................................................ B-6
Table B-6: Beacon Identification and Message Fields ............................................................... B-8
Table B-7: Solution Data Message Fields .................................................................................. B-8
Table B-8: Spacecraft Identification Codes .............................................................................. B-10
Table B-9: Solution Quality Data Message Fields ................................................................... B-13
Table B-10: Special Alert Message Formats ............................................................................ B-16
Table B-11: SARP Calibration Data Message Fields ............................................................... B-21
Table B-12: SARR Calibration Data Message Fields............................................................... B-21
Table B-13: SARP Control Message Formats .......................................................................... B-22
Table B-14: SARR Control Message Formats ......................................................................... B-22
Table B-15: SGB Information from TAC ................................................................................. B-25
Table B-16: Operational Message Templates ........................................................................... B-26
Table B-17: QMS Message Templates ..................................................................................... B-38
Table C-1: FGB Encoded Location Precision .......................................................................... C-18
Table D-1: MCC Backup Agreements ........................................................................................ D-5
Table D-2: MCC Backup Actions............................................................................................... D-6
Table E-1: Space Segment Providers and Contributors to the Space Segment ........................... E-4
Table F-1: LUT Commissioning Documents .............................................................................. F-3
Table F-2: Spacecraft Commissioning Documents ..................................................................... F-5

1-1

1.
INTRODUCTION
1.1
Purpose
This MCC Handbook is intended as a guide for the operational personnel at a Cospas-Sarsat Mission
Control Centre (MCC), which is a key part of the Cospas-Sarsat System. The Cospas-Sarsat data
distribution network, which is comprised of the Cospas-Sarsat MCCs, ensures that the incident alert
data that has been generated by the System is sent to the appropriate authorities for action.
The purpose of this MCC Handbook is to introduce new MCC operators and managers to the Cospas-
Sarsat System and to describe the skills and competencies that are required of an MCC operator. It
includes descriptions of the roles, responsibilities, and functions of an MCC and of the operators of the
MCC.
This Handbook should be used in conjunction with many other available resources, which may include
one or more of:
• the Cospas-Sarsat operational System documents,
• the Cospas-Sarsat technical System documents,
• Cospas-Sarsat training videos,
• the model course described in an annex of document C/S P.015, “Cospas-Sarsat Quality
Manual”,
• other Cospas-Sarsat documents,
• site-specific training and manuals that describe the regulations and the procedures that are
established by the Ground Segment Provider responsible for this MCC,
• vendor-specific training on the equipment that is used at this MCC.
Note that all of the Cospas-Sarsat documents and videos are available on the Cospas-Sarsat website (at
www.406.org). If any contradictions exist between this Handbook and another C/S document, then the
associated information in the other C/S document should be considered to be true. The Cospas-Sarsat
Secretariat should be notified of the discrepancy, so that the contradictory information can be corrected.
An important role of this Handbook is to facilitate high-level understanding of the System through the
associated documents. Any MCC operator training will require augmentation that is specific to national
requirements.

1-2

1.2
Scope
This Handbook is provided as a general guide to the operations of the MCCs of the Cospas-Sarsat
System.
More comprehensive and detailed specifications that describe the Mission Control Centre are contained
in the operational documents. The specifications and descriptions of the other parts of the Cospas-Sarsat
System are available in other System documents, many of which are identified in this Handbook. All
of these System documents are available on the Cospas-Sarsat professional web sub-site under
<DOCUMENTS>; alternately, they can be obtained from the Cospas-Sarsat Secretariat.
1.3
Document Organization
This MCC Handbook consists of six chapters, which provide the general outline of the information that
is needed by an MCC operator. The body of this Handbook is supplemented by several Annexes that
address specific aspects of an MCC.
The structure of the body of this Handbook is outlined in Table 1-1.
Table 1-1 – Structure of the MCC Handbook
Chapter
Description

A general introduction to the document

A general description of the Cospas-Sarsat Programme

An overview and description of the operational concepts of the Cospas-Sarsat
System

A description of the Cospas-Sarsat MCC and a review of the requirements for
an operational MCC

A description of the operations that are required of a Cospas-Sarsat MCC

A description of the functions that are expected to be performed by a Cospas-
Sarsat MCC operator
The Annexes to this MCC Handbook are included to provide more detailed explanations of specific
aspects of a Cospas-Sarsat MCC and of its operation. These Annexes are listed in Table 1-2.

1-3

Table 1-2 – Annexes to the MCC Handbook
Annexes
A
An explanation of the data distribution rules for incident alert data, as laid out
in the Cospas-Sarsat Data Distribution Plan (document C/S A.001, the DDP)
B
A description of the Subject Indicator Type (SIT) messages that are defined in
the Cospas-Sarsat Standard Interface Description (document C/S A.002, the
SID) and that are used by the Cospas-Sarsat MCCs
C
An explanation of the location data concepts and the terminology that are used
in connection with the Cospas-Sarsat Ground Segment, and more specifically
with the incident alert data
D
A description of the contingency procedures that are used by MCCs in support
of the Cospas-Sarsat data distribution system
E
An explanation of the unique requirements that apply to various specialized
Cospas-Sarsat MCCs
F
A summary of the functions that an MCC is expected to provide in support of
the Cospas-Sarsat Quality Management System and the Cospas-Sarsat System
Monitoring and Reporting capabilities
- END OF SECTION 1 –

2-1

2.
THE COSPAS-SARSAT PROGRAMME
2.1
General
The Cospas-Sarsat Programme operates a satellite-based beacon alert communication system in
support of Search and Rescue (SAR) operations around the world. This System uses spacecraft
and ground facilities to detect and locate distress signals from 406 MHz emergency beacons that
are carried on boats and aircraft, and by individuals. The distress alert information derived from
these beacon signals, including the position of the distress beacon and other related information
(such as the information provided when the beacon was registered), is sent through the data
distribution network, which is comprised of Cospas-Sarsat MCCs, to the appropriate SAR
authorities.
2.2
History
Search and Rescue has a long history of adapting the available technology to help those in distress.
With the development of radio electronics after the Second World War, beacons were developed
that enabled the operators of ships and airplanes to transmit distress signals to alert people that
their vessel was in trouble, and to lead the rescuers to the scene of the incident. These beacons
were designed to be heard through the radio receiver of an over-flying airplane.
While this was a definite advance over previous capabilities, there remained many areas, such as
the oceans and the far north, where there were not enough aircraft flying on a regular basis to make
this a complete solution to the problem of identifying and locating distress incidents.
The development of satellite technology in the nineteen sixties and seventies led researchers in
several countries to look for a further advance: placing receivers on satellites to relay the signals
to receiving ground stations. The culmination of this research in several countries was the Cospas-
Sarsat System.
During the twentieth century, there was also a strong movement towards the internationalization
of many activities. The International Telegraph Union (formed in the middle of the nineteenth
century) and the International Radiotelegraph Union (formed at the beginning of the twentieth
century) combined in 1947 to form the International Telecommunication Union (ITU). Following
on the Titanic disaster, the Safety of Life at Sea (SOLAS) convention and other international
conventions eventually led to the establishment of the Inter-Governmental Maritime Consultative
Organization (IMCO) in 1959, which was renamed the International Maritime Organization (IMO)
in 1982. The Chicago Convention on International Civil Aviation, ratified in 1947, established the
International Civil Aviation Organization (ICAO) to foster the planning and development of
international air transport to ensure safe and orderly growth. All of these organizations have been
established as organs of the United Nations.

2-2

The Search and Rescue Satellite-Aided Tracking (SARSAT) program began as a cooperative effort
among the governments of Canada, France, and the United States of America (USA). At the same
time, the government of the Union of Soviet Socialist Republics (USSR) was developing a similar
program called Космическая система поиска аварийных судов, a Russian phrase that means
Space System for the Rescue of Vessels in Distress. Transliterated from the Cyrillic it became
Cosmicheskaya Sistema Poiska Avariynich Sudov, which was then abbreviated to COSPAS.
Encouraged by the various international organizations that were involved in the organization of
Search and Rescue (especially by ICAO and IMO, with support from ITU), these nations came
together to discuss the sharing of this technology. In an agreement that was a significant
accomplishment during the Cold-War era, a Memorandum of Understanding (MOU) was signed
in 1979. This was followed by a second MOU in 1984, and then by the International Cospas-Sarsat
Programme Agreement (ICSPA), which was signed by representatives of the four Party states
(Canada, France, the USA, and the USSR) in July 1988 and subsequently ratified by each of their
governments.
The ICSPA provided a stable environment for other nations that wanted to participate in the
Programme. By this agreement, the Parties agreed to provide their continued support for the space
segment. Knowing that the space segment would be available, other countries could safely invest
in the ground infrastructure that enabled them to participate in (and contribute to) the Programme.
The original agreement was for fifteen years, and it provided for automatic extension at set
intervals after that time. Although the USSR, one of the original signing Parties, was dissolved in
1991, the Russian Federation has assumed its place, and the agreement has continued without
interruption. The ICSPA has been extended as required. As of 2023, the programme has grown to
include forty-five participating countries and organizations. A complete list of Participants is
maintained by the Cospas-Sarsat Secretariat in document C/S P.010, “List of States &
Organizations Associated with or Contributing to the Cospas-Sarsat Programme”.
The four Parties to the ICSPA each supply a part of the Space Segment for the System:
• The USA supplies the satellite platforms and the launch capability for the SARSAT
satellites.
• Canada supplies the Search and Rescue Repeater instruments for the SARSAT satellites.
• France supplies the Search and Rescue Processor instruments for the SARSAT satellites.
• The Russian Federation supplies the COSPAS satellites, including all of the Search and
Rescue payloads.
Although the ICSPA was only written to address the LEOSAR system, it has been interpreted to
allow the expansion to the GEOSAR and MEOSAR systems. Additional contributions to the Space
Segment have been provided by the European Commission, India and China (P.R. of). Separate
agreements have been signed to document these contributions to the Cospas-Sarsat System. These
agreements are captured in individual documents, as listed in Table 2-1.
The ICSPA is currently (in 2023) under review by the Parties, with a view to bringing it up to date
with the current realities of the Programme.

2-3

Table 2-1 – Space Segment Agreement Documents
Document
Number
Title
P.008
Arrangement on Cooperation between Cooperating Agencies of Parties to the
International C/S Programme Agreement and European Organisation for
Exploitation of Meteorological Satellites (EUMETSAT) on EUMETSAT
Contribution to C/S GEOSAR System
P.009
Understanding Between States Parties to International C/S Programme
Agreement and Republic of India Concerning Association of Republic of India
with C/S Programme as a Provider of Geostationary Satellite Services for Search
and Rescue (GEOSAR)
P.014
Declaration of Intent for Co-operation on the Development and Evaluation of the
Medium Earth Orbit Search and Rescue (MEOSAR) Satellite System between
the Co-operating Agencies of the International Cospas-Sarsat Programme and
the Galileo Joint Undertaking
P.017
Declaration of Intent Between Co-operating Agencies of International
C/S Programme and European Commission for Co-operation on Initial
Operational Capability of C/S Medium-Altitude Earth Orbit Search and Rescue
(MEOSAR) Satellite System
P.018
Declaration of Intent with China for Co-Operation on MEOSAR; unsigned,
courtesy translation. The original document was signed in the English, French and
Russian languages, those versions all being equally authentic.
The Cospas-Sarsat System was originally designed around the distress beacons that were in
existence in the early 1980s, which transmitted a pulsed signal at 121.5 MHz. The signals from
these beacons were intended to be detected by radio receivers on over-flying aircraft. They were
designed neither for satellite relay nor for automated detection and processing. At that time there
were about half a million of these beacons in operation and the System had to be made to work
with them.
The first prototype of the Cospas-Sarsat ground station (the Local User Terminal, or LUT) was
designed and built by a Canadian company, in cooperation with the Canadian Communications
Research Centre (CRC). This system showed that a computer could detect and locate emergency
beacons by monitoring signals relayed over a satellite link.
At the same time, the French space agency, CNES, was operating the Argos system for the
detection and location of scientific platforms that carried specialized beacons. CNES believed that
this capability should be incorporated into the new Cospas-Sarsat System; this led to the
development of the specification for a new Cospas-Sarsat distress beacon, which would operate at
406 MHz. In 1985, there were only a few test beacons operating at this frequency; in 2023, the
number of these beacons is estimated to have grown to over three million operational beacons.
Since 2009 (when the satellite support for the 121.5 MHz beacons was turned off), the operational
Cospas-Sarsat System detects and processes only the signals in the 406 MHz frequency band.

2-4

The first satellite of the Cospas-Sarsat System, Cospas-1, was launched by the USSR on 1 June
1982. At the time, there were only a few LUTs in operation, including those of the four founding
Parties to the ICSPA. One of the key features of the ICSPA was the requirement that all of the
national systems should be interoperable; that is, they should be capable of working together. This
approach was confirmed on 10 September 1982, when the first Cospas-Sarsat rescue was based on
data collected through a Soviet satellite (Cospas-1) and processed by the Canadian LUT.
From the time of that first rescue to the end of 2019, the Cospas-Sarsat System has contributed to
the Search and Rescue efforts in more than fifteen thousand distress incidents, during which more
than fifty thousand people in distress have been rescued.
For a more detailed description of the history of the Cospas-Sarsat Programme, the reader is
referred to the document “The History and Experience of the International Cospas-Sarsat
Programme for Satellite-Aided Search and Rescue”, which was prepared and edited by Daniel
Levesque, the first Head of Cospas-Sarsat Secretariat. The document is available on the Cospas-
Sarsat website under the <DOCUMENTS> tab: “History and Experience of the Programme”.
2.2.1
Stakeholder Organizations
As noted in the description of the history of the Cospas-Sarsat System, above, three international
organizations were deeply involved in the establishment of this System:
• the International Civil Aviation Organization (ICAO),
• the International Maritime Organization (IMO),
• the International Telecommunications Union (ITU).
Each of these organizations contributed to the establishment of the Cospas-Sarsat Programme;
they are all major stakeholders in the Programme.
As a part of their regulatory activities, ICAO and IMO prescribe the requirements for the carriage
of Cospas-Sarsat distress beacons: Emergency Locator Transmitters (ELTs) and Emergency
Position Indicating Radio Beacons (EPIRBs), on aircraft and ships, respectively. These
requirements, as implemented by the member States of these organizations, are a driving force
behind the use of these beacons around the world.
ITU regulates the use of the frequency bands that are reserved for the use of the international search
and rescue satellite system; as such, it is a major player in the management of the technical aspects
of the Cospas-Sarsat System.
These organizations, and their significance to the Cospas-Sarsat System, are described in the
following sections. They each produce many documents; some of the documents that are relevant
to the Cospas-Sarsat Programme are listed on the Cospas-Sarsat website, under the <DOCUMENTS>
tab: select <REFERENCE MATERIAL FOR INTERNATIONAL ORGANIZATIONS>.

2-5

In particular, it should be noted that ICAO and IMO jointly publish the International Aeronautical
and Maritime Search and Rescue (IAMSAR) Manual, which contains guidelines for Search and
Rescue in terms of both shipping and aviation. The IAMSAR Manual consists of three volumes:
•   Volume I. Organization and Management,
•   Volume II. Mission Co-ordination,
•   Volume III. Mobile Facilities.
The purpose of a common manual is to ensure that cooperation between the two areas of operation
is effective, and that operational cooperation can be carried out in actual rescue operations between
different organizational and rescue units. It is important to ensure smooth cooperation between the
two areas because many ship and aircraft accidents involve both ships and aircraft in the search
and rescue operations.
The International Civil Aviation Organization
The International Civil Aviation Organization (ICAO) was established in 1947 with the ratification
of the Chicago Convention on International Civil Aviation (the Chicago Convention) by half of
the States that had participated in the convention. Later that year, it became an agency of the United
Nations. In 2023, essentially all of the countries of the world are member States of ICAO. More
information about ICAO is available on its web site, at www.ICAO.int.
ICAO, through its governing Council, adopts standards and recommendations for the regulation
of many aspects of international air transport, including:
• Air navigation and the supporting infrastructure,
• Flight inspection,
• Prevention of unlawful interference,
• Facilitation of border-crossing procedures,
• Air accident investigation.
ICAO has updated the Chicago Convention several times since its original development and has
established a series of Annexes to the convention, as listed in Table 2-2.

![Image 1 from page 23](/images/cospas-sarsat/G-series/G010/G010_page_23_img_1.png)

2-6

Table 2-2 – Annexes to the Chicago Convention
Annex
Title

Personnel Licensing

Rules of the Air

Meteorological Service for International Air Navigation

Aeronautical Charts

Units of Measurement to be used in Air and Ground Operations

Operation of Aircraft

Aircraft Nationality and Registration Marks

Airworthiness of Aircraft

Facilitation

Aeronautical Telecommunications

Air Traffic Services

Search and Rescue

Aircraft Accident and Incident Investigation

Aerodromes

Aeronautical Information Services

Environmental Protection

Security

The Safe Transport of Dangerous Goods by Air

Safety Management
With its long history of support for aviation-related SAR activities, as mandated by Annexes 11
and 12 to the Chicago Convention, ICAO has been supportive of the development of the Cospas-
Sarsat Programme. The use of Cospas-Sarsat in many aviation incidents has established ICAO as
a major stakeholder in the Programme.
In response to several recent incidents, ICAO is in the process of developing the Global
Aeronautical Distress and Safety System (GADSS). Amendments to the Annexes 6 and 12 have
been approved, and the system is scheduled to be implemented early in the 2020s. The GADSS
will apply to all international commercial aircraft, and will require:
• automatic monitoring of aircraft position at fifteen-minute intervals,
• in the event of a potential distress condition, autonomous monitoring of the aircraft position
at one-minute intervals,
• collection of information that will provide the location of a crash site within six nautical
miles,
• establishment of a Location of an Aircraft in Distress Repository (LADR), to be used by
Airlines, Air Traffic Control Centres, and Rescue Coordination Centres to support aircraft
that are in distress.
Since ICAO is a major stakeholder in the Cospas-Sarsat System, the Programme is developing
new technology, such as the distress tracking ELT(DT), and associated data distribution
capabilities to support the GADSS initiative.

2-7

Section A.4.7.3 of this Handbook describes the features of the data distribution that will be
supported for the distress tracking ELTs.
The International Maritime Organization
The International Maritime Organization (IMO) is a specialized agency of the United Nations
which is responsible for regulating international shipping. IMO was established as the Inter-
Governmental Maritime Consultative Organization (IMCO), following agreement at a UN
conference held in Geneva in 1948, and it met for the first time in 1959. It became IMO in 1982.
IMO was established to consolidate the international conventions which had previously been
adopted piecemeal, such as the Safety of Life at Sea Convention (SOLAS), first adopted in 1914
following the Titanic disaster, and the International Convention for the Prevention of Pollution of
the Sea by Oil (OILPOL). IMO has built on and expanded these (and other) agreements to develop
and maintain a comprehensive regulatory framework for shipping. Its current responsibilities
include safety, environmental concerns, legal matters, technical co-operation, maritime security
and the efficiency of shipping. More information about IMO is available on its web site, at
www.IMO.org.
The membership of IMO consists (in 2023) of the 173 States which have ratified the Convention
on the International Maritime Organization, including almost all of the member states of the United
Nations that have a seacoast.
The work of IMO that is related to Sea Safety and Search and Rescue is handled by the Maritime
Safety Committee (MSC), which (under Article 28(a) of the Convention on the IMO): “shall
consider any matter within the scope of the Organization concerned with aids to navigation,
construction and equipment of vessels, manning from a safety standpoint, rules for the prevention
of collisions, handling of dangerous cargoes, maritime safety procedures and requirements,
hydrographic information, log-books and navigational records, marine casualty investigation,
salvage and rescue, and any other matters directly affecting maritime safety.” The Sub-Committee
on Navigation, Communications and Search and Rescue (NCSR) supports the MSC in the
development of regulations and procedures related to Search and Rescue.
The Global Maritime Distress and Safety System (GMDSS) is an internationally agreed-upon set
of safety procedures, types of equipment, and communication protocols used to increase safety
and make it easier to rescue distressed ships, boats and aircraft. In 1988, IMO amended the Safety
of Life at Sea (SOLAS) Convention to require the ships that are subject to that convention
(essentially, all large commercial shipping) to carry GMDSS equipment. Among other items, this
equipment includes the 406 MHz satellite EPIRBs (Emergency Position Indicating Radio
Beacons) that are supported by the Cospas-Sarsat System. This equipment has been required on
all SOLAS ships since 1999. With the implementation of the GMDSS, the Cospas-Sarsat System
has become an essential part of IMO regulations for the safety of shipping at sea.

![Image 1 from page 25](/images/cospas-sarsat/G-series/G010/G010_page_25_img_1.png)

2-8

The International Telecommunications Union
The International Telecommunication Union (ITU) is a specialized agency of the United Nations
that is responsible for issues that concern information and communication technologies.
ITU coordinates the shared global use of the radio spectrum, promotes international cooperation
in assigning satellite orbits, works to improve telecommunication infrastructure in the developing
world, and assists in the development and coordination of worldwide technical standards. ITU is
also active in the areas of broadband Internet, latest-generation wireless technologies, aeronautical
and maritime navigation, radio astronomy, satellite-based meteorology, convergence in fixed-
mobile phone, Internet access, data, voice, TV broadcasting, and next-generation networks. More
information about ITU is available on its web site, at www.ITU.int.
ITU grew out of the International Telegraph Union (established by the International Telegraph
Convention agreed in Paris in 1865) and the International Radiotelegraph Union (established in
1906 at the first International Radiotelegraph Convention in Berlin). In 1932, a joint conference
decided that the Telegraph Convention of 1875 and the Radiotelegraph Convention of 1927 were
to be combined into a single convention, the International Telecommunication Convention,
embracing the three fields of telegraphy, telephony and radio. The two organizations were merged
into a single entity, the International Telecommunication Union. In 1947, an agreement between
ITU and the newly created United Nations recognized ITU as the specialized agency for global
telecommunications, and on 1 January 1949, ITU officially became an organ of the United Nations.
In 2023, virtually all the member States of the United Nations are members of ITU.
The Sector of ITU that is responsible for radio communication is ITU-R. Established in 1927 as
the International Radio Consultative Committee (the CCIR, from its French name: Comité
consultatif international pour la radio), the CCIR became (in 1992) ITU-R. This Sector of ITU
manages the international radio-frequency spectrum and satellite orbit resources. Of particular
interest to the Cospas-Sarsat programme, ITU-R is the body that authorizes the use of the
frequency bands for satellite-based Search and Rescue communications, and that issues the
recommendations for the protection of those frequency bands:
• The uplink spectrum between 406.0 and 406.1 MHz:
-
Recommendation ITU-R M.633-4: Transmission Characteristics of a Satellite
Emergency Position-Indicating Radio Beacon (Satellite EPIRB) System Operating
through a Satellite System in the 406 MHz Band,
-
Recommendation ITU-R M.1478-3: Protection Criteria for Cospas-Sarsat Search and
Rescue Instruments in the Band 406.0-406.1 MHz,
-
Recommendation ITU-R SM.1051-4: Priority of Identifying and Eliminating Harmful
Interference in the Frequency Band 406.0-406.1 MHz and Monitoring in the Adjacent
Frequency Bands 405.9 406.0 MHz and 406.1-406.2 MHz,
-
Report ITU-R M. 2359-0: Protection of the 406.0-406.1 MHz Band,
• The downlink spectrum between 1,544.0 and 1545.0 MHz:

![Image 1 from page 26](/images/cospas-sarsat/G-series/G010/G010_page_26_img_1.png)

2-9

-
Recommendation ITU-R M.1731-2: Protection Criteria for Cospas-Sarsat Local User
Terminals in the Band 1,544.0 to 1,545.0 MHz.
These Recommendations identify and allocate these frequency bands for use in support of satellite-
based Search and Rescue and ask all the member States of ITU to monitor and protect these bands
from unauthorized usage.
In the context of their role as coordinator for the use of the radio spectrum, ITU requests that Space
Segment and Ground Segment operators register their spacecraft and LUTs to formally benefit
from the protection of the 1544.5-MHz satellite-to-LUT downlink frequency band (ITU-R
M.1731). Administrations that operate MCCs should support the registration of all associated
LUTs, liaising with their national ITU representative.
When a LUT is officially declared at ITU, any interference noted in the received frequency of the
LUT could be brought to ITU and resolved in accordance with appropriate ITU procedures (see
also document C/S A.003 section 5 “Interference Monitoring” for reporting interference). When a
LUT has not been declared to ITU this process is less efficient.
The LUT specification documents C/S T.005 (LEOLUTs), C/S T.010 (GEOLUTs) and C/S T.020
(MEOLUTs) each contain a section 2.4 “Frequency Registration” and an Annex H “Guidelines for
Registration of New […]LUTs with ITU”. Additional information can be found on the ITU web
site (www.itu.int). In support of ITU, many of the Participants in the Cospas-Sarsat System,
especially those who are Ground Segment Providers, monitor the protected Cospas-Sarsat
frequencies, and report to ITU when any unauthorized interference is detected. Although ITU does
not, in itself, have any enforcement powers, it can (and does) exert influence on the regulatory
agencies in the participating States that can (and do) enforce the laws by which the States
implement these recommendations.
2.3
Cospas-Sarsat Website
Cospas-Sarsat maintains a website on which it publishes information about the System and other
information that may be of interest to its users and operators. It can be accessed at the Cospas-
Sarsat home page, http://www.cospas-sarsat.int. The website is divided into two sub-sites:
• the Cospas-Sarsat regular web sub-site,
• the Cospas-Sarsat professional web sub-site.
The regular web sub-site is directed at the general public and to users of the System. Under the
tabs on the front page, this sub-site contains:
• <Beacon Ownership>
Information about the acquisition and use of a Cospas-Sarsat 406 MHz distress beacon,
• <System Overview>
A description of the Cospas-Sarsat System for the general audience,

2-10

• <Media Gallery>
Access to some of the documents that provide general information about the System,
• <About Us>
Information about the structure and organization of the Cospas-Sarsat programme.
The Cospas-Sarsat professional web sub-site is directed at the professionals (and others) who work
with the Cospas-Sarsat System. To access this professional web sub-site, go to the Cospas-Sarsat
home page and select the <COSPAS-SARSAT PROFESSIONALS> button.
The tabs on the front page of the Cospas-Sarsat professional website give access to a great deal of
additional information about the Cospas-Sarsat System, including:
•
<System>
Descriptions of the current status of the various components of the System:
-
The status of the Space Segment,
-
A detailed description of the LEOSAR and GEOSAR systems,
-
The Cospas-Sarsat Quality Management System (QMS),
-
Supplementary information about the MEOSAR system.
•
<Beacons>
Descriptions of the support available for Cospas-Sarsat 406 MHz beacons:
-
The registration of a distress beacon,
-
General information about the carriage and regulation of distress beacons,
-
A program to decode the digital message sent by a beacon.
•
<Documents>
A list of all of the System documents (see section 2.4 of this Handbook).
•
<Meetings>
The schedule of meetings, including for each meeting:
-
the papers submitted for discussion,
-
the report of the meeting.
•
<Contact Lists>
-
Information about all the Cospas-Sarsat Mission Control Centres,
-
Information about other web sites that may be of interest,
-
Contact information for the Cospas-Sarsat Secretariat.

2-11

Some of the information on the professional web sub-site is protected by account and password
access. Accounts are available to authorized agencies and personnel and are issued (and annually
renewed) by the Cospas-Sarsat Secretariat to official Representatives. These Representatives then
distribute the passwords as required within their national programmes.
The Cospas-Sarsat documents that are referenced in this MCC Handbook are all available on the
Cospas-Sarsat professional web sub-site (under the <DOCUMENTS> tab).
2.4
Cospas-Sarsat Reference Documents
The tables in the following sections of this Handbook contain lists of the Cospas-Sarsat documents
that are referenced in this MCC Handbook; these documents are recommended for a more
complete understanding of the operation of a Cospas-Sarsat MCC.
The acronyms and other Cospas-Sarsat terminology that are used in this Handbook (and in many
other Cospas-Sarsat documents) are defined in document C/S S.011, “Cospas-Sarsat Glossary”.
Many (but not all) of the Cospas-Sarsat System documents (including the glossary) are available
in all three of the official languages of the Programme (English, French, and Russian). Some of
the documents are also available in other languages, with translations provided by some of the
Participants in the Cospas-Sarsat System.
A complete list of the Cospas-Sarsat System documents, as well as the text of each of the
documents, is available on the Cospas-Sarsat professional web sub-site (under the <DOCUMENTS>
tab).
2.4.1
General Reference Documents
The documents that are listed in Table 2-3 provide general information for users of the System.
Table 2-3 – General Information Documents
Document
Number
Title
G.003
Introduction to Cospas-Sarsat
G.005
Cospas-Sarsat Guidelines on 406 MHz Beacon Coding, Registration and Type
Approval
G.007
Handbook on Distress Alert Messages for Rescue Coordination Centres (RCCs),
Search and Rescue Points of Contact (SPOCs) and IMO Ship Security
Competent Authorities
G.010
MCC Handbook
S.007
Handbook of Beacon Regulations
S.011
Cospas-Sarsat Glossary

2-12

The document C/S G.003 is a general introduction to the Programme and to the System; it is
directed at people who are new to and not familiar with the Programme.
The document C/S G.005 provides information about how the data should be encoded in a Cospas-
Sarsat 406 MHz distress beacon.
The document C/S G.007 contains the descriptions and explanations of the contents of the distress
alert message that are sent to the RCCs and SPOCs by the Cospas-Sarsat MCCs. These are the SIT
185 messages, and this information supplements the explanations of the SIT messages in ANNEX
B of this Handbook.
The document C/S S.007 provides a list of information, provided by Participating States of the
Cospas-Sarsat Programme, on the regulations that are imposed by various nations for the encoding
and operation of 406 MHz distress beacons. This Handbook is maintained by the Cospas-Sarsat
Secretariat from the contributions provided by each of the States that regulates the use of these
beacons.
The document C/S S.011 includes information about all the acronyms and about many of the terms
that are specific to the Cospas-Sarsat Programme.
Cospas-Sarsat also publishes some other documents of general interest:
• the Information Bulletin contains information about the current status of the System,
• the System Data Document contains specific detailed information about the various
components of the Cospas-Sarsat System.
These documents are issued at regular intervals by the Cospas-Sarsat Secretariat; they are also
available on the Cospas-Sarsat professional web sub-site.
2.4.2
Programme Documents
Table 2-4 contains a list of the Programme documents that are referenced in this Handbook, and
that describe the organizational structure of the Cospas-Sarsat System.
The Programme documents also include the agreements that have been signed with the Space
Segment providers, as listed in Table 2-1.
Table 2-4 – Programme Documents
Document
Number
Title
P.001
International Cospas-Sarsat Programme Agreement
P.002
Procedure for the Notification of Association with the International Cospas-
Sarsat Programme by States Non-Party to the Cospas-Sarsat Agreement
P.007
Guidelines for Participating in the Cospas-Sarsat System

2-13

P.010
List of States & Organizations Associated with or Contributing to the Cospas-
Sarsat Programme
P.011
Cospas-Sarsat Programme Management Policy
P.015
Cospas-Sarsat Quality Manual
2.4.3
Operational Documents
Table 2-5 is a list of the operational documents for the Cospas-Sarsat System. These documents
describe the Cospas-Sarsat Data Distribution System and contain the essential details of the
operational requirements for a Cospas-Sarsat Mission Control Centre.
Table 2-5 – Operational Documents
Document
Number
Title
A.001
Cospas-Sarsat Data Distribution Plan
A.002
Cospas-Sarsat Standard Interface Description
A.003
Cospas-Sarsat System Monitoring and Reporting
A.005
Cospas-Sarsat Mission Control Centre Performance Specification and
Design Guidelines
A.006
MCC Commissioning Standard
2.4.4
Technical Documents
The documents that are listed in Table 2-6 address the technical components of the Cospas-Sarsat
System; in particular, they define and describe the 406 MHz distress beacons, the Cospas-Sarsat
Space Segment, and the Local User Terminals of the Cospas-Sarsat Ground segment.
Table 2-6 – Technical Documents
Document
Number
Title
T.001
Specification for [First-Generation] Cospas-Sarsat 406 MHz Distress Beacons
T.002
Cospas-Sarsat Local User Terminal [LEOLUT] Performance Specification and
Design Guidelines
T.003
Description of the 406-MHz Payloads Used in the Cospas-Sarsat LEOSAR
System
T.004
Cospas-Sarsat LEOSAR Space Segment Commissioning Standard
T.005
Cospas-Sarsat LEOLUT Commissioning Standard
T.006
Cospas-Sarsat Orbitography Network Specification

2-14

Document
Number
Title
T.007
Cospas-Sarsat 406 MHz [First-Generation] Distress Beacon Type Approval
Standard
T.009
Cospas-Sarsat GEOLUT Performance Specification and Design Guidelines
T.010
Cospas-Sarsat GEOLUT Commissioning Standard
T.011
Description of the 406-MHz Payloads Used in the Cospas-Sarsat GEOSAR
System
T.012
Cospas-Sarsat 406 MHz Frequency Management Plan
T.013
Cospas-Sarsat GEOSAR Space Segment Commissioning Standard
T.015
Cospas-Sarsat Specification and Type Approval Standard for 406 MHz Ship
Security Alert (SSAS) Beacons
T.016
Description of the 406-MHz Payloads Used in the Cospas-Sarsat GEOSAR
System
T.017
Cospas-Sarsat MEOSAR Space Segment Commissioning Standard
T.018
Specification for Second-Generation Cospas-Sarsat 406 MHz Distress Beacons
T.019
Cospas-Sarsat MEOLUT Performance Specification and Design Guidelines
T.020
Cospas-Sarsat MEOLUT Commissioning Standard
T.021
Cospas-Sarsat Second-Generation 406-MHz Distress Beacon Type Approval
Standard
T.022
Cospas-Sarsat MEOSAR Reference Beacon Network Design Guidelines
2.4.5
IBRD Documents
The documents that are listed in Table 2-7 address the requirements and operations of the Cospas-
Sarsat International 406 MHz Beacon Registration Database (IBRD).
Table 2-7 – IBRD Documents
Document
Number
Title
D.001
Functional Requirements for the Cospas-Sarsat International 406 MHz Beacon
Registration Database
D.004
Operations Plan for the Cospas-Sarsat International 406 MHz Beacon
Registration Database
2.4.6
Cospas-Sarsat Videos
The Cospas-Sarsat organization has developed a number of video clips that describe and provide
more information about various aspects of the System. Each of these video clips is relatively short,

2-15

with a play time between one and fifteen minutes. Most of these videos are available in English
with French and Russian subtitles. Some videos are also available with Arabic, Greek, Portuguese
and Spanish subtitles.
To access any of these videos, go to the Cospas-Sarsat regular web sub-site and select <MEDIA
GALLERY> and <VIDEOS>; then select and play the video that you want to watch.
Some of the topics that are addressed in these videos include:
• an introduction to and an overview of the Cospas-Sarsat System,
• explanations of why a person should buy a 406 MHz beacon and of how it should be used,
• descriptions of how the System works and of various components of the System,
• a series of frequently asked questions (FAQs) about the Programme and about the System.
The Media Gallery on the Regular web sub-site includes (under <Videos>) a complete list of the
videos that are available at any time.
- END OF SECTION 2 -

3-1

3.
OVERVIEW OF THE COSPAS-SARSAT SYSTEM
Cospas-Sarsat is an international programme that has developed and that operates a satellite-based
system for the detection and location of distress beacons anywhere in the world.
3.1
Mission Statement
“The International Cospas-Sarsat Programme provides accurate, timely and reliable distress alert
and location data to help search and rescue authorities assist persons in distress.”
As stated in the dedication of document C/S P.001, “International Cospas-Sarsat Programme
Agreement” (the ICSPA,), this alert and location data is provided on a non-discriminatory basis:
• It is generated in response to the detection of any beacon, regardless of the nationality of
the person who owns or operates the distress beacon.
• It is distributed, based on the location and the country of registration of the beacon, to the
SAR authorities of the appropriate State(s), regardless of whether they have associated
themselves with the Programme.
3.2
Introduction
The Cospas-Sarsat System uses distress beacons, which transmit signals in the 406 MHz frequency
band that are received by search and rescue instruments on the satellites used by the System.
As illustrated in Figure 3.1, the signals from active distress beacons are relayed through the
satellites to Cospas-Sarsat ground receiving stations, called Local User Terminals (LUTs), which
process the signals to extract the beacon identification data and to determine the location of the
beacon. Each LUT is associated with a Mission Control Centre (MCC) to which the alert data is
forwarded and by which it is then relayed, through a data distribution network of MCCs, to the
appropriate SAR point of contact (SPOC), Rescue Co-ordination Centre (RCC), or other authority,
who is then responsible for the necessary search and rescue activities.

3-2

Figure 3.1: Flow of control
This illustration shows, very briefly, what happens when a 406 beacon is activated.
3.3
Beacon Segment
The Cospas-Sarsat Beacon Segment consists of the 406 MHz distress beacons that are carried on
ships and aircraft, or that are carried by individuals who expect to be in other situations where they
may require assistance. As of 2023, there are over three million 406 MHz distress beacons
available for operational use around the world.
The types of Cospas-Sarsat 406 MHz distress beacons that are used by the Cospas-Sarsat System
include:
• Emergency Locator Transmitters (ELTs, for use on aircraft), including distress-tracking
ELT(DT) beacons,
• Emergency Position Indicating Radio Beacons (EPIRBs, for use on ships), including Ship
Security Alerting System (SSAS) beacons,
• Personal Locator Beacons (PLBs, for use in multiple environments by individuals).
Some examples of each of these types of beacons are illustrated in Figure 3.2. Many of these
beacons are activated automatically in the event of an accident. Others are designed to be triggered
manually; however, once they have been activated, they will transmit their distress messages with
no further intervention.

![Image 1 from page 35](/images/cospas-sarsat/G-series/G010/G010_page_35_img_1.png)

3-3

Figure 3.2: Types of Cospas-Sarsat Distress Beacon
The different types of beacons are designed for use in different environments:
• Aviation:
Emergency Locator Transmitter (ELT) and Distress Tracking ELT(DT) (for
tracking aircraft in potential distress situations),
• Maritime:
Emergency Position-Indicating Radio Beacon (EPIRB) and Ship Security Alerting
System (SSAS) beacon (for security situations on SOLAS vessels), and
• Individual:
Personal Locator Beacon (PLB) (not necessarily linked to an aircraft or a ship).

![Image 1 from page 36](/images/cospas-sarsat/G-series/G010/G010_page_36_img_1.png)

3-4

Figure 3.3: Cospas-Sarsat Distress Beacons
The beacons shown in this illustration are examples of the Cospas-Sarsat distress beacons that are in
use in various environments, including maritime EPIRBs, aviation ELTs, and personal PLBs.
The photographs in Figure 3.3 show examples of some of the Cospas-Sarsat distress beacons that
are in operational use with the System in various environments around the world.
The specifications for the distress beacons that are detected and located by the Cospas-Sarsat
System are contained in the documents that are listed in Table 3-1. These include both the actual
distress beacons (identified as “Distress” in the table) and a range of supporting beacon types
(identified as “Support” in the table).
Table 3-1 – Cospas-Sarsat Beacon Specifications
Document
Type
Title
C/S T.001
Distress
Specification for [First-Generation] Cospas-Sarsat 406 MHz
Distress Beacons
C/S T.006
Support
Cospas-Sarsat Orbitography Network Specification
C/S T.015
Distress
Cospas-Sarsat Specification and Type Approval Standard for 406
MHz Ship Security Alert (SSAS) Beacons
C/S T.018
Distress
Specification for Second-Generation Cospas-Sarsat 406 MHz
Distress Beacons
C/S T.022
Support
Cospas-Sarsat MEOSAR Reference Beacon Network Design
Guidelines
Document C/S T.012, “Cospas-Sarsat 406 MHz Frequency Management Plan”, describes the
allocation of frequency channels within the 406 MHz frequency band that is allocated (by ITU)
for the transmission of distress signals to satellite systems for the support of Search and Rescue.

![Image 1 from page 37](/images/cospas-sarsat/G-series/G010/G010_page_37_img_1.png)

![Image 2 from page 37](/images/cospas-sarsat/G-series/G010/G010_page_37_img_2.png)

![Image 3 from page 37](/images/cospas-sarsat/G-series/G010/G010_page_37_img_3.png)

3-5

ICAO and IMO, as well as Cospas-Sarsat, require that all nations that support the use of distress
beacons maintain a register of these beacons. For each beacon, the beacon registry should contain:
• the beacon’s unique identifier,
• the beacon country code,
• the beacon type (ELT, EPIRB, or PLB),
• the identification of the vessel on which the beacon is carried:
-
for an EPIRB, the ship that carries the beacon,
-
for an ELT, the aircraft on which the beacon is installed,
-
for a PLB, the person who will be carrying the beacon,
• information about the type of vessel on which the beacon is carried; for example, the
number of people on board and the size and type of the vessel,
• contact information for a person who should be aware of the use of this beacon (and who
should be available if the beacon is activated).
In addition, any other information that may be of use to the Search and Rescue personnel in the
event of a distress incident could be included in the beacon registry.
To support those nations which do not have their own beacon registry, the Cospas-Sarsat
Programme
operates
an
International
Beacon
Registration
Database
(IBRD,
at
406registration.com). This database, which is maintained by the Cospas-Sarsat Secretariat, allows
countries to designate the IBRD as their beacon registry. It is available free of charge to the owner
and operator of the beacon. It provides twenty-four-hour access to the beacon registration
information that is provided by the owner of the beacon, for the use of MCCs and RCCs in support
of their SAR activities. Document C/S D.004, “Operations Plan for the Cospas-Sarsat International
406 MHz Beacon Registration Database”, provides information about the IBRD.
3.4
Space Segment
The Cospas-Sarsat Space Segment includes all the spacecraft that are used by the System. This
includes spacecraft that are in three different types of orbit around the Earth:
• LEOSAR spacecraft are in Low-Altitude Earth Orbit (LEO), at altitudes between 700 km
and 1000 km above the surface of the Earth. These spacecraft carry two types of Search
and Rescue instruments:
-
The Search and Rescue Repeaters (SARRs) receive and relay the beacon signals
immediately to any LEOLUT that is within the visibility region below the satellite
when the beacon is active. This provides a local coverage capability in the area around
each LEOLUT.
-
The Search and Rescue Processors (SARPs) receive and measure the beacon signals;
they have a store-and-forward capability that enables them to store and later transmit

3-6

the signals to any LEOLUT that is in view of the satellite. This capability provides the
LEOSAR system with global coverage.
• MEOSAR spacecraft are in Medium-Altitude Earth Orbit (MEO), at altitudes between
20,000 km and 24,000 km above the surface of the Earth. Each MEOSAR satellite carries
a SARR instrument that will relay any 406 MHz beacon signal that it receives to all
MEOLUTs that are visible to it. Because of the wide area that is visible to each of the
MEOSAR satellites, this is sufficient to provide global coverage with a relatively small
number of operational MEOLUTs.
• GEOSAR spacecraft are in Geostationary Earth Orbit (GEO), at altitudes of approximately
thirty-six thousand kilometres above the surface of the Earth. Each GEOSAR satellite
carries a SARR instrument that will relay any 406 MHz beacon signal that it receives to all
GEOLUTs that are tracking it. With a relatively small number of satellites and GEOLUTs,
the GEOSAR system provides complete global coverage for all regions below about 70°
latitude. However, the GEOSAR system does not provide any independent location
capability; the only location data available through the GEOSAR system is the encoded
location that may be provided in the beacon message.
The illustrations in Figure 3.4 provide a visual comparison of the relative visibility areas of the
satellites of each of the constellations used in the Cospas-Sarsat Space Segment.

3-7

Figure 3.4: Cospas-Sarsat Satellite Visibility
These diagrams illustrate the area of the surface of the Earth that is visible to a satellite of each of
the Space Segment. Each LEOSAR satellite provides visibility for approximately 4% of the Earth’s
surface, MEOSAR 35% and GEOSAR 38%.
In 2023, the LEOSAR and GEOSAR systems are fully operational, and the MEOSAR system is
at an Initial Operational Capability (IOC). The Space Segment Providers for the operational
satellites in each of these Space Segments are identified in Table 3-2. The number of operational
satellites in each part of the Cospas-Sarsat Space Segment is available on the Cospas-Sarsat
website, under the <SYSTEM> tab: “Current Space Segment Status and SAR Payloads”.

![Image 1 from page 40](/images/cospas-sarsat/G-series/G010/G010_page_40_img_1.png)

3-8

Table 3-2 – Cospas-Sarsat Space Segment
Segment
Satellites
Space Segment Provider
LEOSAR
SARSAT\*
COSPAS
Canada / France / USA
Russian Federation
MEOSAR
SAR/Galileo
SAR/Glonass
SAR/GPS
DASS
European Commission
Russian Federation
Canada / USA
United States of America
GEOSAR
GOES
MSG
MTG
INSAT
Louch
Electro-L
United States of America
European Commission
European Commission
India
Russian Federation
Russian Federation
Note that, in addition to the operational satellites that are listed on the web site, there are frequently
additional satellites that are in various stages of preparation and test, including several on-orbit
standby satellites that are ready for operation whenever they may be called on.
3.5
Ground Segment
The Cospas-Sarsat Ground Segment is comprised of:
• A network of satellite ground stations, called Local User Terminals (LUTs):
-
Low Earth Orbit Local User Terminals (LEOLUTs)
A LEOLUT tracks each LEOSAR satellite that passes over it and receives the
downlink signals from it. It detects and extracts the beacon messages from these
downlink signals and determines the time and frequency when each beacon message
is received at the spacecraft:
▪
For SARP data, it extracts the measurements from the Processed Data Stream
that is sent from the SARP instrument,
▪
For the SARR data, it measures the time and frequency when the data is received
at the LEOLUT, and corrects it to compute the values that would apply at the
spacecraft.
Using this data, it performs Doppler location processing to determine an independent
location estimate for the beacon.
* For the Sarsat LEOSAR satellites, Canada provides the SARR instruments, France provides the SARP instruments,
and the USA provides the satellite platforms.

3-9

-
Medium Earth Orbit Local User Terminals (MEOLUTs)
A MEOLUT tracks as many MEOSAR satellites as it can and receives the downlink
signals from them. (Because a MEOLUT must track multiple satellites simultaneously,
many MEOLUTs use phased-array antennas that can be software-controlled to support
several independent antenna beam patterns from one antenna.) The MEOLUT detects
and extracts the beacon messages from these downlink signals and measures the time
and frequency when each beacon message is received. Using this data, it performs the
Difference of Arrival (DOA) location processing to determine an independent location
estimate for the beacon.
-
Geosynchronous Earth Orbit Local User Terminals (GEOLUTs)
A GEOLUT usually tracks a single GEOSAR satellite and receives the downlink
signals. It detects and extracts the beacon messages from these downlink signals and
measures the time and frequency when each beacon message is received. However,
because the GEOSAR satellites have negligible motion relative to the GEOLUT, the
GEOLUT cannot determine an independent location estimate for the beacon.
Each LUT is associated with a Mission Control Centre (MCC). For each beacon that it
detects, the LUT sends the solution data to its associated MCC. This solution data includes
the beacon message; if the beacon message includes an encoded position estimate, that data
is included in the message that goes to the MCC.
• A network of Mission Control Centres
A Cospas-Sarsat MCC is the focal point for the System operations in each Ground Segment
Provider State. All the MCCs are connected through a network of communications links.
Together, this network of MCCs comprises the Cospas-Sarsat data distribution system,
which is capable of sending the incident alert data generated by the LUTs to the Search
and Rescue authorities who are responsible for responding to the distress situation and
rescuing the people who are at risk.
The Cospas-Sarsat Ground Segment (in 2023) consisted of 32 Mission Control Centres (MCCs)
in operation and  more than 100 Local User Terminals (LUTs). A complete list of Ground Segment
Providers is available in document C/S P.010, “List of States & Organizations Associated with or
Contributing to the Cospas-Sarsat Programme”. At any time, the list of operational MCCs and of
operational LEOLUTs and GEOLUTs is available on the Cospas-Sarsat website, under the
<SYSTEM> tab: “List of LEOLUTs/GEOLUTs”. As the MEOSAR system becomes operational,
the list of MEOLUTs has been added to the website.
- END OF SECTION 3 -

4-1

4.
THE MISSION CONTROL CENTRE
4.1
Overview
A Mission Control Centre (MCC) in the Cospas-Sarsat Ground Segment is defined as a functional
entity; there is no Cospas-Sarsat specification for how an MCC should be implemented. Although
there is no explicit requirement that the MCC should be automated, every operational MCC in the
Cospas-Sarsat System includes a computer system that manages the processing and distribution of
data through that MCC.
Figure 4.1 illustrates the Concept of Operation of the Cospas-Sarsat System and shows where the
Mission Control Centre fits in this concept.
Figure 4.1: Cospas-Sarsat Concept of Operations
This diagram illustrates the Concept of Operations of the Cospas-Sarsat System, showing the MCC
among the different components of the System.
4.1.1
Functions of an MCC
Figure 4.2 is a functional block diagram for a typical MCC, and the illustrations in Figure 4.3 show
some of the equipment that is included in a typical MCC system.

![Image 1 from page 43](/images/cospas-sarsat/G-series/G010/G010_page_43_img_1.png)

4-2

Figure 4.2: Typical Cospas-Sarsat MCC Functional Block Diagram
This diagram is based on the layout shown in document C/S A.005, “Cospas-Sarsat Mission Control
Centre Performance Specification and Design Guidelines”
The requirements for a Cospas-Sarsat MCC are described in document C/S A.005, “Cospas-Sarsat
Mission Control Centre Performance Specification and Design Guidelines”.
4.1.2
Operational Requirements
The operational requirements for a Cospas-Sarsat MCC are listed in Chapter 3 of the MCC
Specifications. In addition to the general requirements for an MCC, these operational requirements
include:
• Availability: An MCC is a critical part of the Cospas-Sarsat System, which is required to
be available and accessible at all times.
• LUT Coordination: For a Ground Segment Provider that operates one or more LUTs, the
MCC is responsible for the coordination of the LUT operations with the rest of the Cospas-
Sarsat System.
• Data Communication Links: As a key component of the Cospas-Sarsat data distribution
network, the MCC is responsible for the maintenance and operation of the communication
links that connect it to the other MCCs and to the local Search and Rescue agencies or other
responsible authorities in the area that it serves.

![Image 1 from page 44](/images/cospas-sarsat/G-series/G010/G010_page_44_img_1.png)

4-3

• Data Formats: The MCC is expected to communicate with other MCCs and with Search
and Rescue Points of Contact (SPOCs) using the message formats and protocols that are
defined in document C/S A.002, “Cospas-Sarsat Mission Control Centres Standard
Interface Description” (the SID,). Although there is no specification for the
communications that are to be used with national LUTs, RCCs, or other competent
authorities, most MCCs use similar network facilities, including the message protocols and
message formats described in the SID, to communicate with these authorities.
• Monitoring of National Ground Segment: An MCC supports the ground segment
capabilities of the Ground Segment Provider that operates the MCC. As such, it is
responsible to monitor all components of its national ground segment. More information
about the system monitoring that is done by an MCC is contained in section 5.3 of this
Handbook.
• Backup Provisions: In order to meet the availability requirements of the MCC
specification, each MCC is expected to have in place suitable arrangements for backup
capability, to be put into effect whenever the MCC cannot perform to specification. These
backup provisions are addressed further in sections 5.2.5 and D.1 of this Handbook.
• Re-routing of Messages: Per bilateral agreement, an MCC may re-route messages for
another MCC.
• Beacon Register: As noted above, every nation is expected to provide for the registration
of distress beacons that are encoded with that nation’s country code. This may be done by
maintaining a separate national beacon registry or by authorizing the registration of these
beacons in the Cospas-Sarsat IBRD. In either case, the MCC is responsible to maintain
access to the beacon register and to provide the beacon registration data to any other MCC
that may request that information.
• Information Archival and Retrieval: As a key operational part of the international Search
and Rescue facilities, each MCC is required to maintain an archive of information
concerning all incident alert data and all messages that it has transmitted or received. The
information that is received by the MCC, including all distress alerts and the associated
information, is maintained in a database, and must be available on request.
• Test and Exercise Coordination and Reporting: An MCC is required to support any tests
or exercises of the Cospas-Sarsat System, or of the various component parts of that System,
that may be approved by the appropriate authorities. After each such test or exercise, the
MCC may have to prepare a suitable report of the events and results of the activity.
• Interference Control: An MCC is responsible for the coordination and reporting of any
frequency monitoring activity conducted by the Ground Segment Provider that operates
the MCC. This specifically includes the reporting of any detected interference in the
frequency bands that are reserved for the use of the Cospas-Sarsat System, either to the
national regulatory authorities or to ITU (or to both, as appropriate).

4-4

• Reference Beacon Operation: The MCC of a Ground Segment Provider that operates a
Cospas-Sarsat reference beacon is responsible for the coordination and the reporting of all
activities related to the operation of that beacon.
• Reporting Requirements: An MCC is required to be able to retrieve and to report on the
performance of the Cospas-Sarsat System, as required by document C/S A.005 (the MCC
specification) and by document C/S A.003, “Cospas-Sarsat System Monitoring and
Reporting”.
4.1.3
Location and Facilities
Beyond the functional requirements listed above, there are no specific requirements for the
location or facilities for an MCC. In summary, an MCC must be located in a place where there are
facilities to support:
• The personnel who operate the MCC,
• The equipment used by the MCC,
• The communications that are needed by the MCC,
• The maintenance of the MCC.
In practice, many MCCs are located in facilities that are shared with one or more of:
• The offices of the agency that operates the MCC,
• An associated RCC (or related search and rescue facility),
• An associated LUT,
• A reference beacon operated by the same administration,
• A beacon simulator operated by the same administration.
Although almost all MCCs share facilities with one or more of these, there is no requirement that
the MCC facilities be shared with any other facility, or with any specific facility.
In general, the choice of a location for an MCC is determined by the facilities available to the
agency that will operate the MCC and by the access to the power and communications links that
are necessary to the operation of the MCC.
4.1.4
Management and Personnel
An MCC is defined in the Cospas-Sarsat documents as a functional entity, with no specific
requirements for how it should be implemented. However, there is a strong implication that an
MCC must be staffed: many of the functions that are required of an MCC can only be performed
by (or under the supervision of) a human operator.

4-5

All operational MCCs are staffed by an MCC Manager (who may be called the Head of MCC,
MCC Chief Operator, or some similar title) and a number of full-time operators. The operators
perform the day-to-day functions that are necessary to keep the MCC operational, and the manager
directs their performance and intervenes when necessary (possibly because of some unusual
circumstance that may be beyond the capability of the operator).
The MCC is the focus of the operations of the Cospas-Sarsat Programme for each participating
Ground Segment Provider and for its declared Service Area. Each MCC is responsible for the
establishment of procedures for the distribution of Cospas-Sarsat data within its Service Area. In
effect, the MCC manages the Cospas-Sarsat operations for the Participant Administration and
supports the other nations in its Service Area. This responsibility implies several operational
requirements for the MCC and its personnel. These requirements are identified in section 5.1 of
this Handbook.
4.1.5
MCC Equipment
As noted above, there are no explicit requirements for specific equipment to be installed and used
in a Cospas-Sarsat MCC. However, there are very few manufacturers of MCC equipment, and
most MCCs include a computer system and communications equipment that is similar to those
which are shown in Figure 4.3. The illustrations in the Figure show scenes at several typical
Mission Control Centres. The maps, both the physical maps mounted on the walls and the software
maps displayed on the computer terminals, are essential to the operation of an MCC, and provide
a visual background for the incident alert data that is received and processed by the MCC.
The equipment of an MCC includes the communications facilities that are used by that MCC.
Although the equipment that links the MCC computers to the data communications network is
installed in the MCC, this equipment and the actual network facilities may be leased from a
commercial service provider. However, they remain an essential part of the MCC equipment.
The equipment at an MCC must meet the availability requirements of C/S A.005: “The MCC shall
be available to perform its functions 99.5% of the time over a period of one year.” This availability
requirement applies to both the equipment in the MCC and the communications links that are used
by the MCC. Separate - and usually more demanding - reliability requirements are set for each of
the different communications links that an MCC may use.
MCC operators, as shown in these illustrations, are an essential part of the MCC. While much of
the MCC operation can be automated, there are some aspects that can only be performed by a
human operator.

4-6

Figure 4.3: Typical MCC Images
The operation of an MCC is illustrated by these images of typical MCCs that are currently
operational in the Cospas-Sarsat System.
When a new MCC is installed, or after any major change to the MCC equipment or software, the
MCC must be commissioned before it can be operated in the Cospas-Sarsat Ground Segment. The
details of the commissioning procedures and the tests that must be accomplished are described in
document C/S A.006, “Cospas-Sarsat Mission Control Centre Commissioning Standard”.
In addition to ensuring that the equipment is reliable, the MCC must make the arrangements
necessary to provide a back-up capability in the event that the equipment fails. Backup for the
communications services may be provided in a variety of different forms, ranging from alternate
network connections to complete separate communications services.
Regardless of the back-up facilities available at the MCC site, all MCCs prepare a plan to hand
over responsibility for their Service Area to another MCC in the event that the equipment or
services that are used at the operational MCC are not able to provide the necessary level of service.
A description of the backup plans for each MCC is contained in section 5.3 of document
C/S A.001, “Cospas-Sarsat Data Distribution Plan”. Unless these back-up arrangements are called
upon operationally, they must be tested at least once a year.

![Image 1 from page 48](/images/cospas-sarsat/G-series/G010/G010_page_48_img_1.png)

4-7

4.1.6
Automatic Operations
Although there is no explicit requirement that a Cospas-Sarsat Mission Control Centre must
include a computer system, every operational MCC is built around an automated computer system
that performs the bulk of the work required to implement document C/S A.001, “Cospas-Sarsat
Data Distribution Plan” (the DDP), and to format and transmit or to receive and process the
messages that are defined in document C/S A.002, “Cospas-Sarsat Standard Interface
Description”, (the SID).
The illustrations above provide a general outline of the structure of the hardware that is required
to automate a Cospas-Sarsat MCC. The software that is run on this MCC computer system includes
a variety of components to perform the different functions that are required of the MCC; Table 4-1
contains a list of the software components that are most commonly implemented in a functional
MCC.
Table 4-1 – MCC Software Structure
This is a sample list, with descriptions, of the components that might be included in a typical MCC
software package.
Title
Function
Comments
OS
Operating system
Normally a commercial
product, sold by the
manufacturer of the computer
system
Manager
Software to manage and control the other
components of the MCC application
software package
Custom MCC software;
usually designed and built by
the MCC manufacturer.
Comms
Input
Manage the communications receiving
software
May be a combination of a
commercial software
communications package and
custom MCC software.
Input
Processing
Interpret and validate the messages received
from the associated LUTs or from other
MCCs.
Custom MCC software
Beacon
Message
Processing
Extract and validate the beacon message
data from the input messages
Custom MCC software
Location
Processing
Process the position data (encoded location
or independent location) from the incident
alert message
Perform GEOSORT to determine which
SRR contains the alert location
Custom MCC software

4-8

Title
Function
Comments
Routing
Determine the appropriate destination for the
incident alert message
Custom MCC software
Formatting
Generate the SIT message(s) for onward
transmission of the incident alert data
Custom MCC software
Comms
Output
Manage the communications transmission
software
May be a combination of a
commercial software
communications package and
custom MCC software.
Archival
Manage the storage and retrieval of the data
that is processed by the MCC computer
system
Custom MCC software
Operator
Display
Generate data displays for the MCC operator
In most MCC systems, this includes a
geographic map display, as well as text
displays of the data that is processed through
the MCC computer system
Custom MCC software
Operator
Interface
Accept and process commands from the
MCC operator
Custom MCC software
Although a few MCCs have designed and developed their own hardware configurations and
software implementations, the majority of MCCs have purchased their automated systems from
one of the small number of manufacturers of these systems. Representatives of these manufacturers
(as members of the delegations of their customers, who are Participants in the Cospas-Sarsat
Programme) often attend Cospas-Sarsat meetings that discuss and update data distribution
specifications, as a means to help keep their products compliant with related Cospas-Sarsat
requirements. It is then up to each Ground Segment Provider to make the contractual arrangements
that are essential to ensure that the up-to-date versions of the hardware and software are installed
and maintained in their own MCC.
As the specifications and requirements for the Cospas-Sarsat data distribution system are amended,
the Secretariat maintains a list of current modifications, and each Ground Segment Provider is
expected to notify the Secretariat of their plans and schedules for the implementation of these
changes in their own system, and then to notify the Secretariat when their MCC has been updated
to become compliant with each new requirement.
Depending on the nature of the new requirements, the upgraded MCC may have to be put through
a partial (or complete) set of commissioning tests before it can be used operationally. Related
information is provided in document C/S A.006 section “Recommissioning of a Previously
Commissioned MCC”.

4-9

4.2
Processing LUT Data
The Local User Terminal (LUT) is the ground station that receives data, through one or more of
the satellites of the Cospas-Sarsat Space Segment, from an active distress beacon and processes
that data to extract the beacon message and (if possible) determine an independent location
estimate for the beacon. This is the basis of the incident alert data that is distributed through the
MCC to the Search and Rescue authorities.
A Ground Segment Provider that operates an MCC is not required to also operate a LUT. However,
if an MCC has one or more associated LUTs, the MCC is responsible for the management and
coordination of the LUT operations within the Cospas-Sarsat System.
Each LUT may produce an independent location estimate for a beacon alert:
• After each pass of a LEOSAR satellite over the beacon, a LEOLUT generates a Doppler
location estimate for the beacon, if possible. A Doppler solution inherently contains two
different positions.
• After it receives a beacon burst through multiple different satellite channels, a MEOLUT
generates a Difference of Arrival (DOA) location estimate for the position of the beacon,
if possible.
• Every LUT forwards the beacon message to the MCC with the solution data. This beacon
message may contain an encoded position. This encoded position is the only beacon
location estimate that is available from a GEOLUT.
ANNEX C of this Handbook explains many of the concepts associated with the solution data that
is generated by the Cospas-Sarsat LUTs and defines some of the terms that are used in the incident
alert messages.
4.3
Cospas-Sarsat Data Distribution Plan
Document C/S A.001, “Cospas-Sarsat Data Distribution Plan” (the DDP), contains a complete
description of the requirements for the distribution of data through the network of MCCs that
comprise the Cospas-Sarsat data distribution system. That document includes several tables that
identify how each type of message is to be formatted and sent through the system. These tables are
encoded into the computer systems that are run at each MCC, and the decisions and
implementation of the DDP are almost completely automated.
4.3.1
MCC Service Area
When each MCC is installed and commissioned into the Cospas-Sarsat System, a Service Area is
declared by that MCC. In essence, this MCC Service Area identifies the region for which the MCC
will be responsible, and within which the MCC will distribute incident alert data to RCCs and
SPOCs. This area is usually delimited by the boundaries of the Search and Rescue Regions that it

4-10

will serve and identifies the countries that are expected to provide Search and Rescue support
within those regions. The details of the procedures for the assignment of the Service Area of an
MCC are described in section 5.2.2.3 ("MCC Service Areas") of document C/S P.011, “Cospas-
Sarsat Programme Management Policy”.
The following sections contain a brief description of the data distribution system; for a more
detailed explanation of the individual parts of this system, refer to ANNEX A in this Handbook.
Because the location data that are provided with a distress incident alert are only estimates of
position, there is some uncertainty in the location of the distress incident. While document C/S
A.005 only requires that SAR boundaries be implemented in an MCC within a 25 km tolerance,
some MCCs employ buffer SRRs, to ensure that alerts with a location near a SRR boundary are
distributed to all responsible SAR authorities.
Except for Ship Security Alerting System (SSAS) beacon alerts, an MCC is responsible for the
delivery of any alert message with the position in its service area to the SPOC or national RCC
that is responsible for the Search and Rescue Region (SRR) that contains the alert message
position. An MCC delivers alert messages for SSAS beacon for States in its service area to the
competent authority, as designated by the State identified by the country code in the beacon
message, regardless of beacon location. For an alert for which the responsible authority is not in
its service area, the MCC delivers the alert to the appropriate MCC via the nodal MCC network.
4.3.2
DDRs and Nodal MCCs
A nodal MCC is a complete operational MCC, which is expected to have all the capabilities of any
MCC. In addition, a nodal MCC is required to support additional capabilities, which are described
in Chapter 6 of the document C/S A.005.
As described in document C/S P.011, “Cospas-Sarsat Programme Management Policy”, “a nodal
MCC shall coordinate with and act as a focal point for MCCs in its DDR [Data Distribution
Region] on Cospas-Sarsat System matters and provide support and assistance to developing MCCs
within its DDR.” As indicated in Table 4-2 and illustrated in Figure 4.4, the Cospas-Sarsat data
distribution system in 2023 is divided into six DDRs, with six nodal MCCs.
Table 4-2 – Data Distribution Regions
This list identifies each of the existing Data Distribution Regions and the associated nodal MCC.

4-11

DDR
Data Distribution Region
Nodal
MCC
Ground
Segment
operator
CDDR
Central Data Distribution Region
FMCC
France
EDDR
Eastern Data Distribution Region
CMC
Russia
SCDDR
South Central Data Distribution Region
SPMCC
Spain
SPDDR
South Pacific Data Distribution Region
AUMCC
Australia
NWPDDR
North West Pacific Data Distribution Region
JAMCC
Japan
WDDR
Western Data Distribution Region
USMCC
USA
Figure 4.4: Cospas-Sarsat Data Distribution Network
This illustration shows the nodal MCCs and the links that connect the different DDRs of the Cospas-
Sarsat Ground Segment.
The decision of which MCCs will be supported by each nodal MCC is made by the Cospas-Sarsat
Council, based on the mutual agreement of the nodal MCCs and the MCCs that will be supported
by the nodal MCC. The boundaries of the DDR are implicit in the GEOSORT: they are the outer
boundaries of the Service Areas of all of the MCCs that comprise the DDR.
Each MCC must be capable of distributing the incident alert data for any position within its own
Service Area. For a position that is not in its own Service Area, the MCC (if it is not a nodal MCC)

![Image 1 from page 53](/images/cospas-sarsat/G-series/G010/G010_page_53_img_1.png)

4-12

sends the incident alert data to its nodal MCC. The nodal MCC must then determine whether the
position is inside its DDR or not:
• If the position is in the DDR, the nodal MCC will send it to the MCC that is responsible
for the Service Area in which the position is located.
• If the position is not within its own DDR, the nodal MCC will send the incident alert
message to the nodal MCC that is responsible for the DDR in which the position is located.
This procedure minimizes the amount of information that is required to be held in each MCC:
• Any MCC that is not a nodal MCC only has to know the boundaries of the SRR of each
RCC or SPOC within its own Service Area.
• In addition, each nodal MCC must have:
-
within its own DDR:
▪
the boundaries of every MCC Service Area,
▪
the identification and address of the associated MCC,
-
for the rest of the world:
▪
the boundaries of every DDR,
▪
the identification and address of the associated nodal MCC.
At the same time, the structure is sufficient to ensure that the incident alert data will always be sent
to the correct MCC for processing and for eventual distribution to the correct responsible SAR
authority.
It should, however, be noted that the Central Data Distribution Region (CDDR) has implemented
a mesh configuration:
• If the position is in the CDDR, the MCC sends the alert directly to the MCC that is
responsible for the Service Area in which the position is located.
• If the position is not within the CDDR, the MCC message is forwarded to the nodal French
MCC, which routes the message to the nodal MCC responsible for the DDR in which
position is located.
This is an exception to the general rule, which was adopted by mutual agreement among the
Ground Segment Providers in the CDDR.
4.3.3
RCCs, SPOCs and Search and Rescue Regions
The international agreements on Search and Rescue, as defined in the Safety of Life at Sea
(SOLAS) Convention of IMO and in the Chicago Convention of ICAO, define the responsibilities
of the participating States and of the Rescue Coordination Centres (RCCs) that they operate to
perform the activities that are necessary to support Search and Rescue. Each State must identify

4-13

its Search and Rescue Regions (SRRs); that is, the geographical area that is supported by each of
its RCCs.
An MCC's Service Area is that part of the world within which a Cospas-Sarsat alert data
distribution service is provided by that MCC, in accordance with document C/S P.011, “Cospas-
Sarsat Programme Management Policy”. When an MCC is commissioned into the Cospas-Sarsat
System, it is required to declare its Service Area; that is, to identify the list of RCCs and SPOCs
to which that MCC will distribute Cospas-Sarsat alert data. The list of countries / regions included
in the Service Area of each MCC is provided at section 5.3 (Description of Cospas-Sarsat MCCs)
of document C/S A.001 (the DDP).
Document C/S P.011, “Cospas-Sarsat Programme Management Policy”, sets out the policy
considerations for the establishment of MCC Service Areas. It is expected that each MCC Service
Area and its boundaries will be consistent with the areas of national responsibility established by
the International Civil Aviation Organization (ICAO) and the International Maritime Organization
(IMO), and that they will be decided by mutual agreement among all Participants. When it is
impossible to achieve agreement among all the Participants, Cospas-Sarsat will accept that a new
Service Area may overlap with one or more existing MCC Service Areas. In this case, any alert in
the region of overlap will be sent to the MCC or SPOC associated with both of the agreed MCC
Service Areas.
The guidelines for the establishment of a new MCC in the Cospas-Sarsat Ground Segment are set
out in Annex A of document C/S A.006, “Cospas-Sarsat Mission Control Centre Commissioning
Standard”. The Ground Segment Provider is expected to identify its proposed Service Area, and
to provide a set of boundary points for this new MCC Service Area. The proposed Service Area
will be reviewed by the Joint Committee and recommended (as amended, if necessary) to Council
for approval. The Cospas-Sarsat Secretariat will then add these boundary points to the GEOSORT
and make the updated GEOSORT available to all MCCs.
The new MCC must identify each of the RCCs in its declared Service Area and determine which
communication services will be used to communicate with that RCC.
• For an RCC that is operated by a foreign country, the details must be defined in cooperation
with the government of that country. The foreign RCC is known as a Search and Rescue
Point of Contact (SPOC). Communications between the MCC and its SPOCs are
established in accordance with document C/S A.005 sections entitled “Data
Communication Links” and “Data Formats”.
• For an RCC that is operated by the government of the country that is the Ground Segment
Provider for the MCC, then the communications between the MCC and the RCC are an
internal matter, subject to the prerogatives of national sovereignty. However, in fact, most
of the operational MCCs operate their internal communications links to their RCCs using
communications services and protocols that are very similar to the links defined for a
foreign SPOC.

4-14

Document C/S A.005 recommends that the MCC establish appropriate arrangements with all the
Administrations and their SPOCs in its Service Area on communication networks to be used for
the distribution of alert data. If a suitable arrangement cannot be agreed, the MCC is directed to
send the incident alert data to one of its own RCCs and ask that RCC to follow its own SAR
procedures to deal with the incident. These RCC procedures may include provisions to pass the
information to an RCC in the destination country that will then prosecute the incident.
Document C/S A.005 requires that each MCC should maintain at least two separate data
communications links with every SPOC or RCC with which it communicates. This ensures that
there is a reliable backup communications link available, in case the primary link fails. This
document also requires that a link “shall be available for at least 95% of the time during each
calendar day”.
As each new SPOC is identified, either through agreements with Cospas-Sarsat or via other
channels, it will be incorporated into an existing MCC Service Area by mutual consent of the
SPOC national authority and the appropriate MCCs. It is strongly recommended (although not
mandatory) that an MCC should formalize this agreement with a written MCC-SPOC Agreement;
a model agreement is available on the Cospas-Sarsat website under the <DOCUMENTS> tab: select
“Templates and Forms” and then “MCC/SPOC Model Agreement Template”. This agreement
should include a description of any unique arrangements for a particular MCC-SPOC
communications link. All MCCs should be notified when a new SPOC is identified by an MCC.
The reliability of the communication links between an MCC and its supported RCCs (and,
especially, its supported SPOCs) may vary widely, depending on the facilities that are available in
each part of the world. Because of problems that have arisen with some SPOCs in the past, all
MCCs are expected to verify these communications links on a regular basis:
• If the communications links are used operationally (in support of actual Search and Rescue
activities), then the MCC should verify that the operational messages are consistently
received and acted upon as required.
• If there is not much operational activity, then the MCC should send a test message, and
request an active confirmation that the message has been received at the RCC, to each
SPOC at least once a month.
This requirement is stated in section 3.1.4.3 ("MCC to RCC/SPOC Communication Links") of
document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”.
The results of the SPOC communications tests are reported by each MCC to the Cospas-Sarsat
Secretariat, on a monthly basis. The Secretariat summarizes these reports in its annual Report on
System Status and Operations, which is presented to the Cospas-Sarsat Joint Committee for review
at each annual meeting. This data is also presented to the IMO Sub-Committee on Navigation,
Communications and Search and Rescue (NCSR) as part of the annual Cospas-Sarsat status report.
If an MCC finds that it has difficulty getting a message correctly received at one of its supported
SPOCs, then it should communicate with the SPOC and with the national authority that operates

4-15

the SPOC to ensure that any problems are corrected. If necessary, the international organizations
(such as ICAO) may offer some support to the nation that operates the SPOC to ensure that suitable
facilities are available to it.
4.3.4
Alert Data Distribution
The procedures for the distribution of incident alert data are described in document C/S A.001,
“Cospas-Sarsat Data Distribution Plan”. In particular, the rules for the distribution of incident alert
data are set out in a series of tables (called “Processing Matrices”) in section 4 (“Operational
Procedures for Cospas-Sarsat MCCs”) of that document. There is a different table for each set of
conditions under which the message must be distributed.
These processing matrices describe the actions to be taken in various circumstances, as defined by
the inputs available with each incident alert. The inputs and actions are defined in C/S A.001:
Table 4-9 (Definition of the Input, Status and Action Words for 406 MHz Alerts), which is
contained in section 4.2.5.2 (“Definition of Input, Status and Action Words”).
The distribution procedures for incident alert messages are explained further in ANNEX A of this
Handbook.
Characteristics of LEOSAR, GEOSAR, and MEOSAR Alerts
A Cospas-Sarsat incident alert is a report of the detection and location of a distress beacon by the
Cospas-Sarsat System. While all alerts share a lot of common characteristics, there are a few
features that are unique to each of the Cospas-Sarsat detection and processing systems:
• The LEOSAR system provides a dual position estimate for each beacon, with one position
on each side of the satellite orbit plane. A second (independent) position estimate is
required to resolve the ambiguity between the two position estimates. The delay between
the activation of a beacon and the distribution of a confirmed location estimate to an RCC
may be anywhere between a few minutes and eight hours.
• The MEOSAR system typically provides a position estimate within a few minutes of
beacon activation.
• The GEOSAR system typically provides detection within a few minutes of beacon
activation. However, it does not provide any independent position estimate.
All three systems relay the beacon message; if there is an encoded position in that beacon message,
that location data will be available in the incident alert that is generated by the Cospas-Sarsat
System.
ANNEX C of this Handbook contains descriptions of the data that may be included in an incident
alert message derived from each of these sources. The specifications for the message formats and
the message data fields that are used to transmit the alert message data are discussed in more detail
in ANNEX B of this Handbook.

![Image 1 from page 57](/images/cospas-sarsat/G-series/G010/G010_page_57_img_1.png)

4-16

Matching of Beacon Alerts
As each beacon alert is received at an MCC, the data in the alert message is compared to alerts that
have been received previously by the MCC to determine if this alert is a new beacon activation or
if it is an update for an existing beacon activation. (Note that only recent alerts are checked; any
alert that is more than twenty-four hours old will have aged out and will not be considered in this
check.)
The beacon identifier, which is a subset of the beacon message, is used to identify all previously
received alerts for the same beacon. Special rules are used to match the beacon identifier when the
beacon message contains invalid or inconsistent data. See document C/S A.001 section entitled
“406 MHz Beacon Message Validation” for more information.
The specifications for the matching of alert data are contained in document C/S A.001, in the
processing matrix in Table 4-1 (“MCC Data Routing Matrix”) and in the accompanying text in
section 4.1.5 (“Inter-MCC Routing of Alert Data”) of that document. These specifications are
discussed in more detail in section A.4.3 of this Handbook. Document C/S A.002 contains the
specifications for the message formats that are used to transmit the alert data; these formats are
discussed in more detail in section B.5 of this Handbook.
Unlocated Alerts
In some cases, an incident alert will not include any location data. This may happen if:
• The beacon message did not include an encoded location, because:
-
The beacon did not have encoded location capability,
-
The beacon did not receive enough data to compute an encoded location,
-
The beacon message was determined not to be a valid message.
• The LUT did not receive enough data from the beacon to compute an independent location:
-
A LEOLUT requires at least three data measurements to compute a Doppler position
estimate,
-
A MEOLUT requires data received through at least two different satellites, with
sufficient spatial separation, to compute a DOA position estimate,
-
A GEOLUT is not, because of the nature of a geostationary orbit, capable of computing
an independent position estimate.
For a given alert, if the beacon message did not include encoded location and the LUT did not
compute an independent location, the incident is an unlocated alert, and the incident alert data
cannot be distributed on the basis of the location.
If the beacon message for an unlocated alert is valid (as defined in the appropriate beacon
specifications document), then the country code in the message is used to determine the destination

![Image 1 from page 58](/images/cospas-sarsat/G-series/G010/G010_page_58_img_1.png)

![Image 2 from page 58](/images/cospas-sarsat/G-series/G010/G010_page_58_img_2.png)

4-17

of the incident alert message. Otherwise, the information in the alert is not reliable or useful, and
no incident alert message is reported.
The specifications for processing unlocated alerts are contained in document C/S A.001, in the
first column of the processing matrix in Table 4-10 (“Processing Matrix, Message Formats and
Distribution of New 406 MHz LEOSAR/GEOSAR Alerts”) or Table 4-11 (“Processing Matrix,
Message Formats and Distribution of New 406 MHz MEOSAR Alerts”), and in the accompanying
text in section 4.2.5.3.1 (“Processing Before Position Confirmation”) of that document. These
specifications are discussed in more detail in section A.3 of this Handbook. Document C/S A.002
contains the specifications for the message formats that are used to transmit the unlocated alert
data; these formats are discussed in more detail in section B.5.1 of this Handbook.
Confirmation of Beacon Positions
The beacon position provided in an incident alert that has been received from only one independent
source is unconfirmed and may not be reliable. A second position, which matches the original
position within 20 km, for the same beacon must be received from an independent source before
the beacon position can be considered confirmed.
Two sources of data for the position of a beacon are considered to be independent as follows:
• an encoded location and a MEOSAR DOA location,
• an encoded location and a LEOSAR Doppler location,
• two MEOSAR DOA locations computed from data received through different sets of
satellites (i.e., each satellite set has at least one unique satellite) and different beacon
transmissions (i.e., there is at least a 2-second time separation in some portion of the time
period associated with each DOA position) or the last detect time for the two DOA alerts
differs by at least 30 minutes,
• a MEOSAR DOA location and a LEOSAR Doppler location,
• two LEOSAR alerts containing Doppler locations that have been computed from data
collected on different satellite passes over the beacon.
On the other hand, the following pairs of alerts would not be considered independent:
• two encoded locations (even if they were received through different spacecraft or different
LUTs, since the source of the data is in the beacon),
• two LEOSAR alerts containing Doppler locations that have been computed from the same
satellite pass over the beacon,
• two LEOSAR alerts containing Doppler locations that have been computed from passes of
different satellites over the beacon, if the two satellites are in the same (or almost the same)
orbital plane, where each Doppler position in one alert matches a Doppler position in the
other alert within 20 km,

![Image 1 from page 59](/images/cospas-sarsat/G-series/G010/G010_page_59_img_1.png)

4-18

• two MEOSAR DOA locations computed from data received through the same set of
satellites, with last detect times within 30 minutes of one another.
As explained in the following paragraphs, the processing of the new alert will vary, depending on
whether or not this is a confirmed position alert.
As explained in section C.1.2 of this Handbook, the LEOSAR Doppler processing generates a
solution with two different position estimates, on different sides of the satellite orbit plane, and it
also provides an estimate of the relative probability that each position identifies the correct
location. Normally, for each incident, one of these positions will be close to the correct beacon
location, and the other solution will be the image (the correct location reflected in the orbit plane
of the satellite).
Since the probability computed by the LEOLUT is not a sure indication of the image solution, the
MCC must wait until the solution can be confirmed by an independent position estimate before it
can resolve the ambiguity of these two solutions. The ambiguity resolution process is described in
section C.1.2.1 of this Handbook.
Document C/S A.002 contains the specifications for the message formats that are used to transmit
the alert data; these formats are discussed in more detail in ANNEX B of this Handbook. The
specifications for the message formats that are used to transmit alert data with an unconfirmed
position are described in section B.5.5 of this Handbook. The specifications for the message
formats that are used to transmit alert data with a confirmed position are described in section B.5.6
of this Handbook.
Special Alert Processing
There are some cases where special processing is required to determine when and where the
incident alert message should be sent. These special cases are addressed in ANNEX A of this
Handbook, in the sections listed in Table 4-3.
Table 4-3 – Special Processing
This table identifies the circumstances that require special processing, and points to the sections in
ANNEX A of this Handbook that describe the processing that is done in each circumstance.
Special Circumstance
Processing Reference
Ship Security Alerting System (SSAS) beacon
A.4.7.1
Notification of Country of Registry (NOCR)
A.4.7.5
Return Link Service (RLS) beacon
A.4.7.2
Distress Tracking ELT – ELT(DT)
A.4.7.3
System Beacon
A.4.7.4
Cancellation Message
A.4.7.5

![Image 1 from page 60](/images/cospas-sarsat/G-series/G010/G010_page_60_img_1.png)

4-19

4.3.5
System Data Distribution
System Data is the information that is required by the various components of the Cospas-Sarsat
Ground Segment to ensure that they will be able to perform the functions that are required of them.
System Data messages include the narrative messages that are used to send status and other
information between MCCs. Table 8 contains a summary of the System data and of the SIT
message formats and data fields that are used for the distribution of System data. System data
message formats are described in more detail in ANNEX B section B.6, and in the tables that are
included in that Annex.
Table 4-4 – System Data
This table summarizes the system message formats and the message data fields that are specific to
these System Messages.
System Data
SIT Message
Numbers
Satellite orbital data
215, 216, 217
SARR & SARP Calibration
415, 417, 510
SARP Telemetry
416, 425, 435, 445
SARR Teemetry
515, 525, 535, 545
Status and narrative
605, 915
Beacon registration
925, 926, 927
Each MCC normally maintains orbital data for each operational LEOSAR, GEOSAR and
MEOSAR satellite and calibration data for each operational LEOSAR satellite. This data is
distributed through the MCC network by the MCC of the Space Segment Provider that is
responsible for that part of the Cospas-Sarsat Space Segment.
The MCC is required to use orbital data for LEOSAR, GEOSAR and MEOSAR satellites to
validate whether position data provided in alert messages is within the footprint of associated
satellites at the time the beacon was detected. The MCC is required to ensure that its associated
LEOLUTs have up-to-date orbital and SARP calibration data for all operational LEOSAR
satellites.
When an MCC receives a System Data Message that contains satellite orbit or calibration data, it
must validate the data (by comparing it with the data it already has). If the new data is within an
acceptable tolerance of the old data, then the MCC should use the new data. If the new data is out
of tolerance from the old data, then the MCC operator should be notified.
The specifications for the processing of system data messages are contained in document
C/S A.001, in the routing matrix in Table 4-1 (MCC Data Routing Matrix), in the processing
matrix in Table 4-2 (System Information Distribution), and in the accompanying text in
section 4.1.6 (Inter-MCC Routing of System Information). These specifications are discussed in

4-20

more detail in section A.7 of this Handbook. The specifications for the message formats that are
used to transmit the system data are discussed in more detail in sections B.6 and B.7 of this
Handbook.
Where the text in ANNEX A indicates that the System Data is to be forwarded to the associated
LUTs, this only applies if the MCC has one or more associated LUTs of the indicated type.
Narrative Messages
A narrative message is a free-format message that is used to communicate between MCC
operators. Although some narrative messages may be generated automatically by the software of
an MCC computer system, many narrative messages are typed in by the MCC operator and sent
on request of the operator.
These narrative messages may serve a variety of purposes, including (for example):
• Request for re-transmission of a message that was not correctly received at the MCC,
• Inquiries about problems with the processing or communications from another MCC,
• Request for additional information about an alert or System data message,
• Notification of planned tests or other (non-distress) beacon activation.
The specifications for the processing of narrative messages are discussed in more detail in
section A.7.5 of this Handbook.
Document C/S A.002 contains the specifications for the message formats that are used to transmit
a narrative message; these formats are discussed in more detail in section B.7 of this Handbook.
There are samples of narrative messages in Chapter 6 and in ANNEX B of this Handbook.
System Status
A system status (SIT 605) message is a narrative message that is transmitted to all MCCs to
indicate changes in System status and to provide beacon test notification. System status messages
include System element and System function failures, scheduled maintenance, integration or
testing of new System elements, and the commissioning of new equipment or new capabilities of
existing equipment. A system status message may be generated automatically by the MCC
computer system or it may be generated manually by the MCC operator. The specifications for the
processing of system status messages are discussed in more detail in section A.7.5 of this
Handbook.
Document C/S A.002 contains the specifications for the message formats that are used to transmit
a system status message; these formats are discussed in more detail in section B.6.5 of this
Handbook. There are samples of system status messages in Chapter 6 and in ANNEX B of this
Handbook.

![Image 1 from page 62](/images/cospas-sarsat/G-series/G010/G010_page_62_img_1.png)

![Image 2 from page 62](/images/cospas-sarsat/G-series/G010/G010_page_62_img_2.png)

4-21

Satellite Orbit Data
Orbit data for the LEOSAR and MEOSAR satellites is normally generated by the Space Segment
Provider that is responsible for the satellite to which the data applies. This information is generated
automatically for the MCC operated by that Space Segment Provider and is formatted and
transmitted to all MCCs once a day. They are also transmitted as needed after every satellite
manoeuvre.
The format of this data normally depends on the Space Segment concerned:
• The LEOSAR orbit data is normally sent as orbit position and velocity vectors in the
SIT 215 or SIT 216 message format.
• The MEOSAR orbit data is normally sent as Two-Line Elements (TLEs) in the SIT 217
message format.
• The GEOSAR orbit data is not automatically distributed.
The orbit data must be verified by the MCC when it is received, as discussed in section 4.3.5 of
this Handbook.
Once it has been validated, the orbit data may be used in the MCC to predict and/or schedule
upcoming satellite passes should be transmitted to any associated LEOLUT as needed to ensure
that the LEOLUT has accurate orbit data.
The specifications for the processing of orbit data messages are discussed in more detail in sections
A.7.2 to A.7.2.3 of this Handbook. Document C/S A.002 contains the specifications for the
message formats that are used to transmit an orbit data message; these formats are discussed in
more detail in ANNEX B section B.6.1 of this Handbook.
System Calibration Data
For various parts of the processing done in the Ground Segment of the Cospas-Sarsat System,
some form of calibration data is required. While some of this data can be generated internally by
the LUTs or MCCs that comprise the Ground Segment, this calibration data is normally generated
by the Space Segment Provider that is responsible for the satellite to which the data applies. These
messages are generated automatically for the MCC operated by that Space Segment Provider, and
are transmitted at regular intervals, according to the needs of each satellite constellation:
• the LEOSAR SARP time and frequency calibration data,
• the LEOSAR SARR frequency calibration data.
The system calibration data must be verified by the MCC when it is received, as discussed in
section 4.3.5 of this Handbook.

![Image 1 from page 63](/images/cospas-sarsat/G-series/G010/G010_page_63_img_1.png)

![Image 2 from page 63](/images/cospas-sarsat/G-series/G010/G010_page_63_img_2.png)

4-22

Once it has been validated, the system calibration data should be stored in the MCC, and
transmitted to any associated LEOLUT as needed to ensure that the LEOLUT has accurate
calibration data.
The specifications for the processing of system calibration data messages are discussed in more
detail in section A.7.3 of this Handbook. Document C/S A.002 contains the specifications for the
message formats that are used to transmit a calibration data message; these formats are discussed
in more detail in sections B.6.2, B.6.3, and B.6.5 of this Handbook.
Spacecraft Command and Control Data
At times, it is necessary that the Space Segment Providers issue commands to manage their
spacecraft systems, or that they receive status data from the spacecraft. These command and
control messages are normally generated by the MCC operated by one Space Segment Provider
and are sent to another Space Segment Provider. These messages are not normally of particular
interest to any other MCC.
The specifications for the processing of spacecraft command and control data messages are
discussed in more detail in section A.7.4 of this Handbook. Document C/S A.002 contains the
specifications for the message formats that are used to transmit a a spacecraft command and control
data message; however, these formats are not discussed in any more detail in this Handbook.
4.4
Data Communication
An essential part of the Cospas-Sarsat data distribution system is the ability to communicate the
data from an MCC to its destination: either to the next MCC in the network or to the authority that
is the final destination of the incident alert data.
Because of the urgency of the information that is associated with a distress incident, most of these
communications networks are automated. The specifications for the data communications
networks are contained in the SID (document C/S A.002). Most of the data communications
between MCCs and from MCCs to SPOCs are carried over commercial data communications
networks. As the available technology changes, the networks that may be used by the Cospas-
Sarsat data distribution system are updated to keep up with the technology.
To ensure the quality and reliability of the communications that are used by the Cospas-Sarsat data
distribution system, every MCC is required to maintain two separate communications links to
support message exchange with other MCCs.
Despite the fact that most of the communications at an MCC are automated and carried over data
communications links, an MCC is also required to maintain voice communications capabilities.
This is normally done over the Public Switched Telephone Network (PSTN); however, some
MCCs also have radio communications capabilities as well.

![Image 1 from page 64](/images/cospas-sarsat/G-series/G010/G010_page_64_img_1.png)

4-23

In 2023, the data networks that are approved for use in the Cospas-Sarsat data distribution system
are:
• FTP/VPN,
• AFTN/AMHS,
• email (subject to restrictions, as described in section 4.4.1.3 of this Handbook).
Document C/S A.002, “Cospas-Sarsat Standard Interface Description” (the SID), includes a set of
Annexes that describe the protocols that should be used with the various communications networks
that are considered suitable for use with the Cospas-Sarsat data distribution system. These Annexes
are identified in Table 4-5.
Table 4-5 – Network Annexes in the SID
This table lists the networks that are described in the Annexes of the SID (document C/S A.002)
• Annex E & F
Internet File Transfer Protocol (FTP) over a
Virtual Private Network (VPN)
• Annex G
Aeronautical Fixed Telecommunications Network (AFTN) and
Aeronautical Message Handling System (AMHS)2
• Annex I
Electronic Mail (email) over the Internet
The SID also includes an Annex H, which is an “Implementation Plan for New Communication
Links”.
The document C/S A.005, “Cospas-Sarsat Mission Control Centre Performance Specification and
Design Guidelines” contains some guidance about the communications link to be used for each of
the facilities with which an MCC may communicate. In general, the communications links between
MCCs, and between an MCC and the SPOCs that it supports, should be one of the networks that
are described in the SID. However, any MCC and/or SPOC may come to a mutual agreement to
use other communications facilities. The communications between an MCC and its associated
national LUTs or RCCs may be determined by the national Administration, as a matter of national
prerogative.
Document C/S A.002 explicitly requires that each of the communications links that is operated by
an MCC should be independent; that is, each link shall meet the specified requirements regardless
of the traffic on any other link.
Each of these networks is discussed briefly in section 4.4.1 of this Handbook. However, it is noted
that communications network technology is a very technical field, and the user is referred to the
2 The AMHS network is being developed by the International Civil Aviation Organization (ICAO) as a replacement
for the AFTN. The plan is for the new AMHS network to be compatible with the existing AFTN, so the transition
from AFTN to AMHS is not expected to cause any significant issues for the Cospas-Sarsat data distribution system.
Each MCC may move from AFTN to AMHS as the network facilities become available to it.

4-24

specifications in the Annexes to the SID for the detailed information that is necessary for the
specification, procurement, management, and maintenance of the data communications networks
at an MCC.
The next section provides some of the unique requirements for each of the communications links
supported by an MCC.
4.4.1
Communication Links
FTP/VPN
The most widely used form of data communications between Cospas-Sarsat MCCs is the File
Transfer Protocol (FTP) over a Virtual Private Network (VPN) on the Internet (FTP/VPN). In
2023, the Internet is available almost everywhere in the world, and provides an available and
reliable communications capability for the Cospas-Sarsat data distribution network.
The use of a Virtual Private Network ensures the security of the communications for the alert and
system data messages that are used by the MCCs of the Cospas-Sarsat Ground Segment. The
information that is necessary to configure the FTP/VPN communications nodes to operate in the
Cospas-Sarsat data distribution network is provided in the Annexes to C/S A.002, as listed in Table
4-5.
AFTN/AMHS
The Aeronautical Fixed Telecommunications Network (AFTN) is operated by ICAO for the use
of Air Traffic Management Services; it has been made available to Cospas-Sarsat for the
distribution of distress messages between MCCs and from MCCs to RCCs. As of 2023, ICAO is
in the process of upgrading their communications services to the Aeronautical Message Handling
System (more precisely, the ATS Message Handling System for air traffic control) (AMHS). The
two systems are forward compatible, so individual MCCs or RCCs can convert from AFTN to
AMHS without affecting their capability to operate in the Cospas-Sarsat data distribution network.
AFTN and AMHS are text data message systems that are restricted to the used of authorized
terminal operators; most of these operators are components of the international air traffic control
services. The limited access that is provided by this restricted set of connections to the network
assures the security of the data communications, as is necessary for the alert and system data
messages that are used by the MCCs of the Cospas-Sarsat Ground Segment.
The information that is necessary to configure the AFTN or AMHS communications node at an
MCC to operate in the Cospas-Sarsat data distribution network is provided in the Annex to
C/S A.002, as listed in Table 4-5.

![Image 1 from page 66](/images/cospas-sarsat/G-series/G010/G010_page_66_img_1.png)

![Image 2 from page 66](/images/cospas-sarsat/G-series/G010/G010_page_66_img_2.png)

4-25

Email
As noted above, the Internet is available almost everywhere in the world, and provides an available
and reliable communications capability for the Cospas-Sarsat data distribution network. The most
common implementation of this capability is the transmission of email messages around the world.
While this capability can be of use to the Cospas-Sarsat MCCs, it is not recommended for the data
distribution system.
The primary reasons that email is not recommended for use in the Cospas-Sarsat data distribution
network are:
• Security
Emails that are sent over the Internet are not secure. Messages can be captured, read, and
redirected without the approval (or even the knowledge) of the originator of the message.
Addresses can be spoofed – that is, a message can be sent from one system as if it originated
from a different system. Because it is so widespread, the Internet email system has been
the subject of many attacks on the privacy and reliability of the messages that it carries.
• Reliability
The email servers that carry messages over the Internet do not provide any guarantee that
a message will be sent to the intended destination, nor do they provide any guaranteed
method to notify the origin or destination when a message is not sent. For the life-critical
data that is sent through the Cospas-Sarsat data distribution system, this is not acceptable.
Despite these limitations, when other services are not available, the use of email does provide an
alternate capability for an MCC to communicate the alert and system data messages that are used
by the MCCs of the Cospas-Sarsat Ground Segment.
The information that is necessary to configure an email communications node to operate in the
Cospas-Sarsat data distribution network is provided in the Annex to C/S A.002, as listed in Table
4-5.
Fax
Facsimile services are another form of data communications that is available almost everywhere
in the world, and it also provides an available and reliable communications capability that could
be used in the Cospas-Sarsat data distribution network. However, it is not recommended for use
between MCCs in the data distribution system.
The primary reason that fax is not recommended for use in the Cospas-Sarsat data distribution
network is that the data that is received through a fax message is not readily amenable to automated
processing. The message can easily be presented to a human operator, but it cannot easily be
decoded and read (and processed) by a computer. For this reason, the use of fax in the Cospas-
Sarsat data distribution network is normally limited to the transmission of incident alert messages
to a SPOC or an RCC, where the message can be read and understood by a human operator.

![Image 1 from page 67](/images/cospas-sarsat/G-series/G010/G010_page_67_img_1.png)

![Image 2 from page 67](/images/cospas-sarsat/G-series/G010/G010_page_67_img_2.png)

4-26

Messages to be transmitted by fax may be sent automatically from the MCC or may need to be
printed, prior to manual transmission, depending on the MCC fax capability. There are no
directions in C/S A.002 for the configuration or use of a fax communications node to operate with
the Cospas-Sarsat data distribution network.
4.4.2
Interfaces
Each MCC supports several different communications interfaces. The specifications for the
communications services used by an MCC are in document C/S A.005, “Cospas-Sarsat Mission
Control Centre Performance Specification and Design Guidelines”. The general requirements are
identified in section 3.4 of that document and the performance requirements for each type of link
are described in section 5.2 of that document. The following sections describe some of the specific
requirements for each of the different communications links that an MCC may use.
For some of the communications links, the requirements are fairly definitely specified. However,
the internal links within any one nation are subject to national prerogatives and are not explicitly
specified by Cospas-Sarsat. Despite that, most of the internal links follow protocols and procedures
that are very similar (if not identical) to those that are specified for the international
communications.
The Annexes to document C/S A.002 contain the specifications for the selection and configuration
of the communications links that are used by an MCC for communications services. These
specifications are generally followed by almost all MCCs; however, there are a few cases where
some of the details of the required processing are adjusted to meet the requirements of a bilateral
agreement between neighbouring MCCs.
Note that, although an MCC may be required to support multiple communications links, the MCC
specification explicitly states (in section 3.4.11 of C/S A.005) that “MCC data communication
shall be implemented such that all communication links and networks can operate simultaneously
without loss of information.”
The MCC specification (in C/S A.005) does not explicitly require any specific communications
checks or verification procedures, but it does state (in section 5.2 of C/S A.005) that “MCCs shall
implement procedures (e.g., Positive Delivery Notification, Channel Checks, Automatic Resends,
Checksums and Sequential Message Numbers) as needed, to ensure that the performance
requirements in section 5 of this document are met.”
MCC – MCC
The primary communications links in the data distribution system join each MCC to one or more
other MCCs. These links are required to be compliant with the communications requirements
described in the Annexes to the SID.

![Image 1 from page 68](/images/cospas-sarsat/G-series/G010/G010_page_68_img_1.png)

4-27

The MCC specification requires that each MCC should maintain at least two separate data
communications links with every MCC with which it communicates. This ensures a reliable
backup communications link is available, in case the primary link fails.
Although the SID allows the use of three different communications services, almost all MCCs use
FTP/VPN as their primary link to other MCCs and use AFTN/AMHS as their backup link. In a
very few cases, where the available AFTN service may not be reliable, email is used as the backup.
The MCC specification (document C/S A.005, section 5.2.2) requires that the MCC to MCC links
should be capable of transferring data to another MCC “within 10 minutes 99% of the time”, with
less than 0.1% of the data lost or corrupted. The MCC must have an operable communications link
to another MCC “for at least 99% of the time during each calendar day”.
MCC – LUT
The selection of the communications link between an MCC and its associated LUTs is a matter of
national prerogative. The only specification imposed by Cospas-Sarsat is that the LUT must
provide the MCC with all the information that it requires to satisfy the MCC specification
(document C/S A.005). In fact, many MCCs use some variations on the incident alert message
formats and protocols to communicate with their LUTs. However, in cases where the MCC and its
associated LUT(s) are produced by the same manufacturer, internal file structures are often used
for the exchange of data between the MCC and its associated LUTs.
The MCC specification (document C/S A.005, section 5.2.1) requires that the MCC shall receive
“all distress alert data transmitted by a LUT within 10 minutes from the completion of LUT
processing 99% of the time” and “all distress tracking alert data by a LUT within 2 minutes from
the completion of LUT processing 99% of the time”. In both cases, less than 0.1% of the data may
be lost in transit.
MCC – RCC/SPOC
The MCC specification defines the communications between an MCC and its SPOCs. However,
the selection of the communications link between an MCC and its associated RCCs is a matter of
national prerogative.
In fact, most MCCs use the incident alert message formats and protocols that are specified for
communications with SPOCs to communicate with their associated RCCs. Although it may not be
required, this simplifies the arrangements for backups when one MCC fails and has to be supported
by another MCC.
As a recipient of Cospas-Sarsat distress alert data, a SPOC is responsible to:
• conduct SAR actions for any real alert (i.e., distress beacon activation) that is reported to
it by the MCC,
• share information about the results of each beacon activation with its associated MCC,

![Image 1 from page 69](/images/cospas-sarsat/G-series/G010/G010_page_69_img_1.png)

![Image 2 from page 69](/images/cospas-sarsat/G-series/G010/G010_page_69_img_2.png)

4-28

• respond to communications tests performed by the MCC by acknowledging receipt of each
test message.
MCC - RLSP
The MCC specification states that the communications link between an MCC and its associated
Return Link Service Provider (RLSP) is to be determined by mutual agreement between the MCC
and the RLSP. (Note that this only affects an MCC that is supporting the Return Link Service of a
GNSS provider.) The Return Link Service (RLS) is addressed in section A.4.7.2 of this Handbook.
4.4.2.4.1
MCC to Galileo RLSP through FMCC
At the present time, the only operational Return Link Service Provider is the European
Commission (EC), who operate the Galileo GNSS, and who have arranged for the support of the
RLSP through the French MCC (FMCC) system.
When an alert with a confirmed position is received from a Galileo RLS-capable beacon, the
responsible MCCs (i.e., each MCC with the confirmed position in its Service Area and any
associated nodal MCC) must forward that alert to the FMCC via the nodal MCC network. The
FMCC will forward this information to the Galileo RLSP. Using the beacon identification and
position information, the Galileo RLSP then determines the information necessary to send the
acknowledgement message to the beacon:
• the Galileo satellites that will see the beacon,
• the times when the beacon will be visible to those satellites,
• the identifier of the beacon to which the acknowledgement message should be sent.
With this information, the RLSP can schedule the appropriate downlink transmission to the
beacon.
MCC - SSAS Competent Authority
Document C/S A.005 states that the communications link between an MCC and its designated
SSAS Competent Authority is to be determined by mutual agreement between the MCC and each
SSAS Competent Authority. (Note that this affects every MCC that is associated with an SSAS
Competent Authority and their backup MCC.)
The SSAS contact details for ship security competent authorities are made available by IMO
Member States in the IMO Global Integrated Shipping Information System (GISIS) database at
https://gisis.imo.org/Public/Default.aspx. The Maritime Security button, after appropriate login,
provides access to “Proper recipients of SSAS alerts”. Document C/S A.001, section 4.2.8 requires
that “All States wishing to use the Cospas-Sarsat System to relay ship security alerts should make
the necessary arrangements with their associated MCC. Arrangements should include the
identification of the competent authority responsible for receiving the ship security alert and the
communication link to the competent authority”.

![Image 1 from page 70](/images/cospas-sarsat/G-series/G010/G010_page_70_img_1.png)

![Image 2 from page 70](/images/cospas-sarsat/G-series/G010/G010_page_70_img_2.png)

4-29

The availability of SSAS contacts through IMO GISIS does not prevent MCC for routing SSAS
data as described in document C/S A.001.
Figure 4.5: IMO GISIS Maritime Security Website Interface
This illustration shows the interface to be used to find the contact details for SSAS Authorities.
MCC - ICAO Location of Aircraft in Distress Repository (LADR)
Nodal MCCs provide ELT(DT) alert data to the Location of an Aircraft in Distress Repository
(LADR) using Web Services, as described in document C/S A.002 section entitled “Web Service
Communications”. As of mid-2023, details of this interface are still under development.
Operational use of ELT(DT)s  started on 1 January 2023, and the LADR is expected to be in
operation by the end of 2023 or in early-2024.
4.5
SIT Messages
The formats of the messages that are transmitted between MCCs in the Cospas-Sarsat Ground
Segment are defined in the SID. Each of the messages exchanged by MCCs is identified by a
Subject Indicator Type (SIT) number, which is included in the message. This SIT number is used
by both the sending and the receiving computer system.
4.5.1
Introduction
Each SIT number designates a specific type of message that has a fixed format, comprised of
specified message fields. Each SIT number for an alert message provides information about the
status of the beacon activation at the source MCC and/or information on the reason that the alert
message was sent.

![Image 1 from page 71](/images/cospas-sarsat/G-series/G010/G010_page_71_img_1.png)

![Image 2 from page 71](/images/cospas-sarsat/G-series/G010/G010_page_71_img_2.png)

4-30

The formatting of a message according to the SIT number is generally independent of the data
communications network that is used to transmit the message. However, every network imposes
its own requirements on the packaging of the messages that it carries. Therefore, when a message
that is received by an MCC is sent to another MCC, it may be necessary to re-format the message.
An alert message received by an MCC will be formatted differently based on the alert destination
type (e.g., an RCC or an MCC), and in many cases, based on the status of the beacon activation in
the receiving MCC.
4.5.2
MCC to MCC Incident Alert Messages
The formats of the incident alert messages that are used between MCCs are described in
section B.5 of this Handbook.
4.5.3
MCC to RCC/SPOC Messages
The incident alert messages that are sent from an MCC to its associated SPOCs and RCCs are in
the SIT 185 format, which is designed to be read by a human operator. These messages are
described in document C/S G.007, “Handbook on Distress Alert Messages for Rescue
Coordination Centres (RCCs), Search and Rescue Points of Contact (SPOCs) and IMO Ship
Security Competent Authorities”, and they are not explained in this Handbook.
4.5.4
System Information
The system data messages that might be sent from or received by an MCC are in the SIT message
formats described in section B.6 of this Handbook.
4.5.5
Narrative Messages
The narrative messages that might be sent from or received by an MCC are in the SIT message
formats described in section B.7 of this Handbook.
4.6
Quality Management System
The Cospas-Sarsat Quality Management System (QMS) is implemented by the MCCs of the
Ground Segment to assess the accuracy, availability, reliability and timeliness of alert data
generated by LUTs, in accordance with document C/S A.003. Every MCC that has an associated
LUT will receive the data that is collected from the reference beacons that have been designated
for QMS analysis. This data is forwarded to its nodal MCC, which performs the analysis necessary
to evaluate the quality of the data. Each nodal MCC then updates the appropriate status pages on
the Cospas-Sarsat website, to ensure that the current status of each component is correctly
displayed.

4-31

4.6.1
QMS Evaluation
The performance indicators that are evaluated and reported by the Cospas-Sarsat QMS are
identified in the following sections of this Handbook.
When a problem is detected by the QMS processing and analysis, the nodal MCC will provide
notification, to the responsible MCC in a SIT 915 message or to all MCCs in a SIT 605 message,
depending on the significance of the problem, per document C/S A.003. In general, when a
significant problem is detected, a SIT 605 message is sent and the C/S website is updated.
If a significant problem with location accuracy is detected, this notification includes a request that
the responsible MCC suppress all independent location data for operational beacons from the
under-performing system, either Doppler solution data for a LEOLUT & satellite pair or DOA
solution data for a MEOLUT. To ensure that inaccurate solution data is not distributed
operationally, the same data that the responsible MCC is requested to suppress is also suppressed
by:
• the nodal MCC, and
• all Central DDR MCCs (if the responsible MCC is in the Central DDR).
For any System component that does not meet the required standard, the responsible operating
agency is notified (through its associated MCC). That agency is then expected to investigate the
deficiency and to report when the deficiency has been corrected. Following the suppression of
independent location data, its operational use is resumed only after the nodal MCC determines that
relevant accuracy requirements are being met for designated QMS reference beacons.
LEOSAR
For the LEOSAR system, the QMS provides information about the performance of each
combination of LEOSAR satellite and LEOLUT for the following metrics:
• Availability,
• Location accuracy.
For any combination that does not meet the appropriate evaluation criteria, the information is
flagged on the LEOLUT QMS display on the Cospas-Sarsat website (available under the <SYSTEM
MONITORING – AVAILABILITY TABLES> tab).
GEOSAR
For the GEOSAR system, the QMS provides information about the performance of each
combination of GEOSAR satellite and GEOLUT for the following metric:
• Availability

![Image 1 from page 73](/images/cospas-sarsat/G-series/G010/G010_page_73_img_1.png)

![Image 2 from page 73](/images/cospas-sarsat/G-series/G010/G010_page_73_img_2.png)

4-32

For any combination that does not meet the appropriate evaluation criteria, the information is
flagged on the GEOSAR QMS display on the Cospas-Sarsat website (available under the <SYSTEM
MONITORING – AVAILABILITY TABLES> tab).
MEOSAR
For the MEOSAR system, the QMS provides information about the performance of each
MEOLUT for the following metrics:
• Availability,
• Local antenna availability,
• Processing timelines,
• Detection probability,
• Location Probability,
• Location accuracy,
• Quality of location Expected Horizontal Error (EHE) estimate.
For any MEOLUT that does not meet the appropriate evaluation criteria, the information is flagged
on the MEOSAR QMS display on the Cospas-Sarsat website (available under the <SYSTEM
MONITORING – AVAILABILITY TABLES> tab).
MCC
The QMS provides information about the performance of each operational MCC for:
• Availability
For any MCC that does not meet the required standards, the information is flagged on the MCC
QMS display on the Cospas-Sarsat website (available under the <SYSTEM MONITORING –
AVAILABILITY TABLES> tab).
The under-performing MCC is expected to correct the problem as soon as possible. If a problem
is allowed to continue for an extended period of time (as defined in C/S A.003), the under-
performing MCC may be declared CNO (Commissioned, not operational), and eventually removed
from the Cospas-Sarsat data distribution network.
4.6.2
MCC Roles in QMS
Role of Nodal MCC
The nodal MCCs are a key part of the Cospas-Sarsat Quality Management System (QMS). All
data generated from designated reference beacons by Ground Segment components within a DDR
must be forwarded to the associated nodal MCC, which analyzes the data to:
• Compute the required quality performance indicators;

![Image 1 from page 74](/images/cospas-sarsat/G-series/G010/G010_page_74_img_1.png)

![Image 2 from page 74](/images/cospas-sarsat/G-series/G010/G010_page_74_img_2.png)

![Image 3 from page 74](/images/cospas-sarsat/G-series/G010/G010_page_74_img_3.png)

4-33

• Evaluate the performance of each LUT and MCC in its DDR; and
• Report on any anomalies in the status of the Cospas-Sarsat Ground Segment, by:
-
Updating the status display on the Cospas-Sarsat website, and
-
Distributing status update messages to other MCCs, as appropriate.
Based on the performance indicators, and on any other information that is available to it, the nodal
MCC must determine if any Ground Segment component is degraded or not operational, and then
make the appropriate declaration of the system status, so that other Ground Segment Providers can
re-configure their systems, as appropriate. (For example, an MCC may have to filter out incident
alert data from a component that is not capable of meeting its requirements.)
The nodal MCC notifies the responsible MCC of any change of status of the System components
that are associated with it. If the status of a component changes significantly, then the nodal MCC
also notifies all Ground Segment Providers of the change in status. Each MCC operator may then
make whatever configuration changes may be necessary to cope with the change of the System
configuration and to work around any degradation that may have occurred. (For example, an MCC
may be required to relay messages that would otherwise have gone through the degraded MCC to
the appropriate destination RCC.) And when the component returns to full operation the MCC may
have to restore the normal operational configuration.
Role of All MCCs
In support of the Cospas-Sarsat QMS, every MCC is required to send the reference beacon data,
as specified in document C/S A.003 (System Monitoring and Reporting) to its nodal MCC. Beyond
that, its only official responsibility is to respond to any reports of degradation or failure, and to
restore its components of the Ground Segment to full operational status.
However, there are other actions that can be taken by an MCC to ensure that the MCC and its
associated Ground Segment components remain fully operational and compliant with the Cospas-
Sarsat specifications. The document C/S A.003 lists a number of MCC self-monitoring parameters
that an MCC should monitor on a regular basis to ensure that any potential degradation of
performance is detected and corrected before it reaches the point where it is reported by the nodal
MCC under the Quality Management System. There is no requirement that these self-monitoring
parameters be reported or published; the only explicit requirement is that the Ground Segment
components should be maintained in a fully operational state at all times.
- END OF SECTION 4 -

![Image 1 from page 75](/images/cospas-sarsat/G-series/G010/G010_page_75_img_1.png)

5-1

5.
MCC OPERATIONS
5.1
Management
Each MCC is a critical part of the Cospas-Sarsat Ground Segment. As such, it must be available
and ready to function at all times. The MCC specification (document C/S A.005, section 3.2.1)
requires that “Once an MCC has been commissioned and attained Initial Operational Capability
(IOC), it shall be in operation 24 hours per day, seven days a week, and personnel shall be available
to satisfy the operational and performance requirements documented herein.”
This means that an MCC must have personnel available full-time: twenty-four hours a day, seven
days a week. In the event of any unexpected event, personnel must be available and ready to deal
with it.
It must be recognized that the organizations within the administrations that are responsible for the
operation of the Cospas-Sarsat MCCs are varied, and include:
• Government departments and agencies,
• Military services,
• Private contractors.
Each of these organizations has its own internal policies and procedures which must be followed
in the operation of the MCC to meet the requirements set by Cospas-Sarsat. As a result, it is not
possible to identify or define a single approach to the management of an MCC that will work for
all Ground Segment Providers.
It is also noted that some MCCs are co-located with a national RCC, while other MCCs operate
completely independently of the national Search and Rescue infrastructure. The selection and
training of MCC personnel must accommodate and support:
• The organizational structure of the national Administration,
• The organization of the national SAR system,
• The situation of the MCC within the national SAR infrastructure.
The guidelines offered in this manual are based on the operations of many existing MCCs. They
are neither comprehensive nor complete, and they are not intended to preclude other approaches
to the operation of a national or nodal MCC.

5-2

5.1.1
Staffing
Due to the complex and highly technical nature of MCC operations and the continuous evolution
of the MCC requirements, dedicated resourcing and staffing are required to ensure that all the
MCC functions are always performed correctly.
For an MCC to have an operator on-site at all times, a full rotation of operational personnel will
be required. To handle this workload (twenty-four hours per day and seven days per week, year-
round) normally requires an MCC Manager and a minimum of four full-time operators. The exact
number of operational personnel and the rotational schedule that is used by any MCC will be
determined by the policies that control work hours at that MCC site.
The personnel who may be available to operate an MCC will be limited by the nature of the
organization responsible for that operation. However, when personnel are selected, some of the
following areas of knowledge and experience will be useful to the person and to the MCC:
• Search and Rescue operations (both nationally and internationally),
• the region of responsibility of the MCC,
• English-language communications skills,
• communications networks and technology,
• satellite operational issues,
• maritime and aviation operational procedures,
Of course, additional capabilities will be required for the managers and chief operators of an MCC.
5.1.2
Training
When an MCC is commissioned (a Development MCC, or DMCC), one of the requirements is
that the operating Administration must provide assurance that the personnel who will be working
on the DMCC are fully trained and are capable of performing all of the functions that may be
required of them during the operation of the system. Annex G to document C/S A.006 (MCC
Commissioning Standard), the Declaration of DMCC on Operator Capability, includes a list of the
specific capabilities that must be confirmed by the Administration that is requesting that its MCC
be commissioned into the Cospas-Sarsat Ground Segment. This list represents a minimum
requirement for the capabilities of an MCC operator.
The Annexes to C/S P.015, “Cospas-Sarsat Quality Manual”, include an outline for a training
program on the Cospas-Sarsat System, which would be useful for the prospective operators of an
MCC. In additional to this general training on the Cospas-Sarsat System, an MCC operator must
also be trained on the use of the specific equipment that is used by the MCC. This specific training
will normally be available from the manufacturer(s) of that equipment.

5-3

Beyond this specific, hands-on, training of an operator, there is a need for a subsequent phase of
on-the-job training. This training should be provided by an experienced MCC operator, and the
trainee’s progress should be monitored and evaluated throughout the process.
Once it has been accepted as a part of the Cospas-Sarsat Ground Segment, the MCC must provide
whatever training and support may be required to maintain the capability of all of its operational
personnel. This includes updating the knowledge of existing personnel as the Cospas-Sarsat
System, and the MCC procedures and equipment, are enhanced over time, as well as training new
personnel as they are hired by the MCC.
To ensure that their staff remains current and maintains their skill, it is strongly recommended that
each MCC should establish a standard for operator activity, considering their local situation such
as the complexity of their ground segment and staffing models. For example, every MCC operator
might be required to complete at least one full shift, consisting of at least eight hours duty, every
thirty days. Additional individual tasks can also be required on a recurring basis to ensure
proficiency of infrequent items. These can include a quarterly review of emergency activities (such
as backup procedures or responses to equipment or communication failures), annual proficiency
or refresher training events, and written exams. If any operator is not able to achieve the established
performance standard, then an experienced operator should conduct a skills check, and further
training as indicated, for that operator to ensure the continued safe operation of the MCC.
5.1.3
Voice Communications
The MCC is required to maintain voice communications facilities to enable it to contact, as
necessary, other MCCs and any of the alert destinations that are within its Service Area. This is
normally a voice telephone capability, over the Public Switched Telephone Network (PSTN), but
it may also include other communications facilities, such as radio communications facilities and
Internet (voice over Internet protocol – VOIP) links.
5.1.4
Language
The personnel at an MCC must be able to communicate with the RCCs and SPOCs that they
support. This means that personnel must be available who can speak to each of these RCCs and
SPOCs.
Volume I of the International Aeronautical and Maritime Search and Rescue (IAMSAR) Manual,
which is jointly published by ICAO and IMO, says that “The need for RCC staff and SAR unit
crews to be proficient in speaking, writing and comprehending a common language to ensure
effective information transfer is vital to successful conduct of SAR operations. In the case of a
SAR action involving cooperative input from a number of RCCs and SRUs within a region, the
most convenient language may be a common regional language. In the case of a SAR action likely
to extend beyond regional areas, the appropriate common language is English. English, in any
case, serves as the default SAR operational language in all cross-boundary operations where there
is no other common language.”

5-4

Based on this guideline, every MCC should have on duty, at all times, at least one operator who is
competent at communicating in the English language. A minimum level of competence on an
internationally recognized measurement scale (such as the International English Language Testing
System - IELTS - scoring) should be established to ensure that the operators are suitably qualified
to support the MCC operations in communications with other organizations.
In addition, and to the extent that is possible in each national context, it would be advisable to have
available either:
• An operator who can speak the language of each supported SPOC, or
• An interpreter who can provide translation services for the operators, as necessary, when
dealing with foreign SPOCs.
While these are not mandatory, they will obviously facilitate the operations of the MCC in those
situations where they may be called on.
5.2
Daily Operations
The MCC is responsible for the administration and monitoring of the Cospas-Sarsat operations in
its Service Area. This includes:
• Managing all of the national contributions to the Cospas-Sarsat System, including (as
appropriate):
-
The MCC itself,
-
Any part of the Cospas-Sarsat Space Segment that is provided by their national
administration,
-
Any associated national LUTs,
-
Any reference beacons or beacon simulators that are operated by the national
Administration,
-
The communications links between the MCC and each of the national components of
the Cospas-Sarsat System,
-
The communications links between the MCC (if it is not a nodal MCC) and its nodal
MCC,
-
The communications links between the MCC and any other MCC of the Cospas-Sarsat
Ground Segment (as necessary),
-
The communications links between the MCC and each of its supported RCCs or
SPOCs.
• Monitoring the status of the Cospas-Sarsat operations that may affect the MCC Service
Area, including the detection and reporting of any anomalies in any of:
-
The Cospas-Sarsat Space Segment,

5-5

-
The operations of the LUTs within its Service Area,
-
The operation of its own MCC,
-
The operation of its associated nodal MCC,
-
The communications links to its associated nodal MCC,
-
The communications links to other MCCs within the same DDR (as relevant).
• Maintaining an awareness of and an ability to access and search the International Beacon
Registry Database (IBRD) that is operated by Cospas-Sarsat.
• Maintaining an awareness of the contacts in all countries within the MCC Service Area:
-
The communications link addresses that are used to contact its associated RCCs and
SPOCs, and any of the other alert destinations that it supports,
-
The current status of the communications links to each of those alert destinations,
-
The SAR capability of each of the RCCs and SPOCs that it supports,
-
The contact information for each national beacon register,
-
The current status of each national beacon register,
-
The current status of the communications facilities used to access each such register.
• Maintaining an awareness of the back-up arrangements that may affect its operations:
-
The national back-up plans for this MCC,
-
The back-up plan for the nodal MCC,
-
the back-up plans for the other MCCs within the same DDR,
-
The back-up communications facilities for each potential alert destination,
-
The current state of each back-up configuration.
• Collecting and forwarding to the nodal MCC all of the designated data required for the
Cospas-Sarsat Quality Monitoring System (QMS)
As any limitations or failures are reported in the Cospas-Sarsat Ground Segment within its Service
Area, the MCC must distribute the appropriate information to all interested parties, and must take
any action within its capabilities to configure the system to operate in backup mode, and to restore
the system to full operational capabilities as soon as that becomes possible.
5.2.1
Activities for MCC System Manager
The MCC System Manager is the manager of the MCC operations and must be aware of the status
of the MCC, including both the equipment and the personnel, at all times. He or she must also
maintain an awareness of the Cospas-Sarsat System, especially as it may affect the operations of
the MCC.

5-6

Although the MCC System Manager should be available (that is, on call) at all times, it is not
essential for a manager to be on-site all the time. It is necessary only that they should be available
to the duty operator whenever their services may be required.
Some of the duties of the MCC System Manager will be:
• Managing the operations of the MCC, including an awareness and control of the
operational status and conditions:
-
The MCC,
-
The MCC personnel,
-
The MCC equipment,
-
The MCC communications systems,
-
All related national contributions to the Cospas-Sarsat System.
• Managing the support for the testing of various parts of the Cospas-Sarsat System,
including:
-
Spacecraft commissioning,
-
MCC commissioning,
-
LUT commissioning,
-
Beacon type approval,
-
Testing of reference beacons and beacon simulators.
•  Liaison with the managers and personnel of:
-
The neighbouring MCCs,
-
All supported RCCs,
-
All supported SPOCs.
• Liaison with the operational staff responsible for the national contributions to the Cospas-
Sarsat System, including (as appropriate):
-
The Space Segment,
-
Any associated LUT,
-
Any reference beacon or beacon simulator,
-
The operational staff at each associated LUT (as appropriate).
• Liaison with others who may be involved (directly or indirectly) in the national
participation in the Cospas-Sarsat Programme:
-
The national Representative to Cospas-Sarsat,
-
The management of the national Agency participating in the Cospas-Sarsat
Programme,

5-7

-
The management of the national agencies who are responsible for Search and Rescue,
-
The management of the national agencies who are responsible for Air Traffic Control,
-
The management of the national agencies who are responsible for the control of
maritime traffic.
• Maintaining an awareness of the current status of all other components of the Cospas-Sarsat
System, including:
-
The Space Segment,
-
The Ground Segment (especially within the local DDR),
-
The distress beacon population,
-
The Search and Rescue authorities and operations with in the MCC Service Area,
• Participation in (or organizing the national delegation for) any meetings that relate to the
operation of the MCC, which may include:
-
National meetings,
-
Meetings of representatives of the local Data Distribution Region, as organized by the
nodal MCC,
-
Cospas-Sarsat Meetings, including (as appropriate for this national delegation)
meetings of the:
▪
Cospas-Sarsat Council,
▪
Cospas-Sarsat Joint Committee,
▪
Experts Working Groups (as invited),
▪
Task Groups,
▪
Correspondence Working Groups,
-
Any other meetings (as appropriate).
These duties and responsibilities will be supplemented, as necessary, by others from time to time.
5.2.2
Activities for MCC Operator
An MCC operator should be capable of performing any of the activities that may be required to
support the national MCC, including:
• Operating and monitoring the operations of:
-
The MCC equipment,
-
The MCC communications links,
-
Any other equipment that is installed at the MCC and used by the MCC during its
operations.

5-8

• Communications with related organizations, including:
-
Other MCCs,
-
Supported RCCs, SPOCs, and other distress data authorities,
-
The organization that manages associated LUTs,
-
The organizations that manage other Cospas-Sarsat ground equipment (such as
reference beacons and beacon simulators).
The MCC operator should also maintain an awareness of the status of the Cospas-Sarsat System,
especially of those components of the System that are within the local DDR and also including the
Cospas-Sarsat Space Segment.
An MCC operator may also be called upon to support any of the activities listed above (in section
5.2.1) for the MCC System Manager. In particular, this may include participation in any of the
meetings that are listed.
5.2.3
Monitoring the Operation of MCC
The operation of an MCC must be monitored at all times, both by the MCC personnel and by the
associated nodal MCC.  This requires that the operator monitor several aspects of the operation of
the MCC:
• The functions and performance of the MCC must be monitored on a regular basis, including
the self-monitoring recommended in section 3.1.4 (MCC Self-Monitoring) of document
C/S A.003. The details of the monitoring that is expected of an MCC are discussed in more
detail in section 5.3.2 of this Handbook.
• The performance of the other components of the national Cospas-Sarsat ground segment
must be monitored, including the self-monitoring recommended in section 3.1 (Ground
Segment Self-Monitoring) of document C/S A.003 and as discussed in more detail in
section 5.3.2 of this Handbook.
• The operation of the MCC must be watched, to ensure that the operator is aware of any
activity that may require human intervention. The following messages must be reviewed
as they are received:
-
Narrative messages,
-
System status messages,
-
Any other messages with information about the state of any part of the System.
In each case, the appropriate action should be taken. If appropriate, a response should be
prepared and sent.
Beyond these specific monitoring capabilities, the personnel at an MCC should maintain an
awareness of the status of operation of all components of the Cospas-Sarsat System and of all

5-9

related and dependent systems that it supports. If any anomalies in the operation of the System are
observed, they should be reported to the appropriate authority.
5.2.4
Test Procedures
An MCC is responsible for coordinating any tests involving C/S beacons that may be performed
within its area of responsibility. This includes the activation of test or reference beacons in support
of:
• Commissioning of LUTs and MCCs,
• Type approval of beacons,
• Beacon tests,
• Search and Rescue tests and exercises,
• Communications tests,
• Cospas-Sarsat System tests.
Related MCC responsibilities are described in sections “Exchange of Test and Exercise Data” and
“Procedures for the Co-Ordination of Beacon Tests” of document C/S A.001.
Commissioning Tests
The Administration that is responsible for the MCC may install or upgrade various components of
the national ground segment. Those Participants who are Space Segment Providers will, at
intervals, launch new spacecraft to serve the System.
As each component is put into place, the associated MCC will be responsible for the coordination
of the tests that are associated with the commissioning of the new components. These
commissioning tests often require the activation of one or more test beacons or beacon simulators
to provide the data needed for the test. The details of the requirement for the commissioning of the
Space Segment and the Ground Segment of the Cospas-Sarsat System are described in more detail
in Annex F.1 of this MCC Handbook.
Beacon Type Approval
Before a 406 MHz beacon can be marketed for use with the Cospas-Sarsat System, it must undergo
a series of rigorous tests to confirm that the design and implementation of that beacon meets the
relevant requirements specified in document C/S T.001 (for First Generation Beacons) or
document C/S T.018 (for Second Generation Beacons). The type approval of a beacon is the
responsibility of the manufacturer of the beacon, and is based on a set of tests and measurements
that are defined in the various type-approval documents that are listed in Table 5-1.

![Image 1 from page 84](/images/cospas-sarsat/G-series/G010/G010_page_84_img_1.png)

![Image 2 from page 84](/images/cospas-sarsat/G-series/G010/G010_page_84_img_2.png)

5-10

Table 5-1 – Beacon Type Approval Documents
Document
Number
Title
T.007
Cospas-Sarsat 406 MHz Distress Beacon Type Approval Standard
T.008
Cospas-Sarsat Acceptance of 406 MHz Beacon Type Approval
Test Facilities
T.015
Cospas-Sarsat Specification and Type Approval Standard for
406 MHz Ship Security Alert (SSAS) Beacons
T.021
Cospas-Sarsat Second-Generation 406-MHz Distress Beacon Type
Approval Standard
C/S T.IP
(LIRB)
Interim Procedure for Type Approval of 406 MHz Beacons
Equipped with Li-Ion Rechargeable Batteries
C/S T.IP
(TCXO)
Interim Procedure for the Determination of Compliance of
406 MHz Beacons Equipped with a TCXO with Cospas-Sarsat
Type Approval Requirements
The type-approval standards define the procedures for the type approval of each type of beacon.
The process begins with an application from the beacon manufacturer, which includes a set of
documents (as listed in each type-approval standard). These documents are reviewed by the
Secretariat and by an Experts’ Working Group (EWG) that is convened by the parties.
Once the application has been reviewed and found to be in order, the type-approval tests and
measurements are performed by a certified test laboratory. The laboratories must have been
certified by the Cospas-Cospas Parties, according to the requirements defined in document
C/S T.008. The other documents that are listed in Table 5-1 describe all of the tests and
measurements that must be performed and reported, for each different type of beacon, before the
beacon can be type-approved.
Once the tests and measurements have been performed, the report of these results is referred back
to the EWG for review. The experts determine whether or not these results confirm that the beacon
meets the relevant requirements. If there are any questions about the results, or about the
performance of the beacon, the report may be sent back to the manufacturer, and clarification or
further tests may be requested.
When the EWG is satisfied that the beacon meets the requirements established by the Cospas-
Sarsat specifications, they recommend that the Parties approve the beacon for use with the System.
The Parties, working through the Cospas-Sarsat Secretariat, assign a Type-Approval Certificate
(TAC) to the beacon, and the beacon may then be marketed as a Cospas-Sarsat 406 MHz distress
beacon.
The beacon type-approval process does not directly involve or require the participation of any
Cospas-Sarsat MCCs. However, some of the type-approval tests may require the activation of a

5-11

test beacon; for all such tests, the MCCs that may be involved must be notified and approve of the
test.
The completion of a successful Beacon Type Approval test does not necessarily qualify a beacon
for operational use. Each Administration defines the rules and regulations that control the use of a
distress beacon within its own jurisdiction. Document C/S S.007 (Handbook of Beacon
Regulations) has been compiled from the contributions of the Participants in the Cospas-Sarsat
Programme to provide regulations for the permitted use of distress beacons in the different
jurisdictions.
Beacon Tests
Live tests of individual beacons may be required for various reasons. One example is the need to
check on the operation of a beacon after it has been involved in an incident, especially if there is
some question about how it performed during that distress incident.
In each such case, the MCC must evaluate the validity of the reason for the test and the potential
impact on any current SAR activity and make a decision on whether or not to allow the test to
proceed.
Search and Rescue Exercises
Exercises that require the activation of a distress beacon may arise through the normal course of
Search and Rescue activity. They may be a part of a national training program or an international
cooperative effort. Or they may be a part of an evaluation of the effectiveness of the Cospas-Sarsat
System or other components of the international SAR programs.
In general, any such exercise will be reviewed and planned by higher-level agencies before they
are proposed to the Cospas-Sarsat MCCs. However, each MCC must evaluate the impact on SAR
activities in its own Search and Rescue Region before it agrees to participate in the exercise, or to
allow the activation of distress (or test) beacons in its Service Area.
5.2.5
MCC Operational Backup
As noted in section 4.1.2 of this Handbook, the MCC must include provision for backup
capabilities. The backup provisions may include the operation of a separate backup MCC system
(complete with separate communications links, as necessary). Alternately the backup may be
implemented by an agreement with a neighbouring MCC to take over some or all of its operations
when the national MCC temporarily fails. In some cases, especially for nodal MCCs, both types
of backup arrangements are set in place.
The backup arrangements for each MCC are documented in the individual entries in section 5.3
(Description of Cospas-Sarsat MCCs) of C/S A.001. Each MCC should ensure that the relevant
section of C/S A.001 specifies whether the backup MCC will support the SPOCs of the failed
MCC directly, or whether it will go through a national point of contact for each SPOC.

![Image 1 from page 86](/images/cospas-sarsat/G-series/G010/G010_page_86_img_1.png)

![Image 2 from page 86](/images/cospas-sarsat/G-series/G010/G010_page_86_img_2.png)

5-12

These backup provisions are addressed further in section D.1 of this Handbook.
5.3
Monitoring and Test Activities
As noted in section 4.1.2 of this Handbook, an MCC is expected to monitor its own performance
and the performance of any other portions of the Cospas-Sarsat System that are operated by the
Administration that is responsible for the MCC.
When an MCC is commissioned, according to the requirements of document C/S A.006 (MCC
Commissioning Standard), it must go through an Initial Operational Capability (IOC) phase, a
period of monitored operations to confirm that it is ready for full operational use. During this IOC,
all other MCCs are expected to monitor the operations of the new MCC to verify that it fully meets
the requirements of the specifications and the operational documents.
The Cospas-Sarsat Quality Management System (QMS) is defined in documents C/S P.015,
“Cospas-Sarsat Quality Manual”, and C/S A.003, “Cospas-Sarsat System Monitoring and
Reporting”. These documents identify some specific requirements for the monitoring of the
operations of an MCC and of the associated national ground segment contributions.
In addition, document C/S A.003 provides descriptions and specifications for a number of MCC
self-monitoring parameters. While the monitoring of these parameters is not officially required of
an MCC, they are recommended to ensure that the MCC management remains aware of the status
of the MCC and the associated LUTs and is aware of any potential degradation before it begins to
affect the operational use of the MCC or the associated LUTs.
Finally, document C/S A.005 (MCC Performance Specification and Design Guidelines) requires
that the MCC “shall monitor the following System elements in its national Ground Segment”:
• Its own (MCC) operations,
• Associated LUTs and LUT/MCC communications links,
• External communications with all data recipients,
• Any anomalies in the operation of the Cospas-Sarsat System.
As any anomaly is detected by the MCC, it should be reported to the associated nodal MCC and
to any other MCC that might be affected by the issue.
5.3.1
MCC Commissioning
As each MCC is developed and introduced into the Cospas-Sarsat System, it must go through a
commissioning process; a set of tests that verify that it meets the required specifications and is
ready to participate in the Cospas-Sarsat Ground Segment at Full Operational Capability (FOC).
The requirements for a Cospas-Sarsat MCC are specified in document C/S A.005 (MCC
Performance Specification and Design Guidelines). The procedures for the commissioning of an

5-13

MCC are described in document C/S A.006 (MCC Commissioning Standard). In addition to the
requirements for the commissioning of every new MCC, the document C/S A.006 also describes
the requirements for commissioning a nodal MCC and for re-commissioning an MCC that has
been modified or enhanced after its original commissioning.
The overall procedure for commissioning is explained in Annex A (“Guidelines for Integration of
New MCCs in the Cospas-Sarsat System”) of C/S A.006, which is provided as “a textual flow-
chart which sketches procedures for integrating an MCC under development (DMCC) into the
existing Cospas-Sarsat Ground Segment”. It is intended to provide guidance to the Joint
Committee “to manage and coordinate the introduction of new MCCs into the existing Ground
Segment” and “to assist the DMCC in planning and performing the appropriate integration tests”.
That Annex A is divided into a series of steps to be followed as the new MCC is developed and
integrated into the System.
Initial Ground Segment Description and LUT Coverage
Step A is to provide information “to assist the Joint Committee in deciding how the DMCC best
fits into the existing System”. This includes information about the LUTs that will be associated
with the DMCC, and about the proposed Service Area of the DMCC.
The DMCC is required to provide the Cospas-Sarsat Secretariat with all the information that will
be required to update the Cospas-Sarsat web site and the Cospas-Sarsat documents (such as
C/S A.001) to include the new MCC.
During this step, the DMCC may propose the host MCC (HMCC), which will coordinate and
oversee the commissioning of the new MCC into the System.
Assignment of Service Area and Message Distribution Procedures
Step B is then intended to “determine the DMCC's responsibilities within the Cospas-Sarsat MCC
network”.
The Joint Committee will select (or confirm, as appropriate) the HMCC for the commissioning of
this DMCC.
The Joint Committee will review the proposed MCC Service Area, following the policy that is
defined in document C/S P.011, “Cospas-Sarsat Programme Management Policy”. During this
stage, the DMCC must identify (and notify the HMCC of) the responsible authorities to which it
will distribute incident alert messages.
Before the start of the formal MCC commissioning tests, the DMCC will perform tests to confirm
that it has the necessary infrastructure in place to format and to transmit the incident alert message
to each of the SPOCs in its proposed Service Area.

![Image 1 from page 88](/images/cospas-sarsat/G-series/G010/G010_page_88_img_1.png)

![Image 2 from page 88](/images/cospas-sarsat/G-series/G010/G010_page_88_img_2.png)

5-14

Integration Test
The formal integration test in Step C is intended to “test the DMCC's operational readiness and
compliance with Ground Segment requirements.”
Based on past experience, it is recommended that the HMCC and DMCC hold a planning meeting
“over two or three days, if necessary”. During this meeting, they can review the results of the
preliminary tests, and can prepare a DMCC Commissioning Test Plan that describes the detailed
plans for the commissioning tests. At this stage, the DMCC must confirm that it understands and
will comply with all the operational requirements for an MCC in the Cospas-Sarsat Ground
Segment.
The commissioning tests will be scheduled, and all MCCs involved will be notified of the planned
tests.
The intent of the commissioning tests is to evaluate all aspects of the operation of the DMCC. This
specifically includes the performance of the DMCC operators. For this reason, the DMCC
commissioning tests should be performed by the people who will operate the MCC when it is fully
operational. Other personnel, including management, maintenance staff, and vendor support
persons, may respond to requests (in the same way as they might during normal operations).
However, they should not conduct the tests or operate the MCC during the commissioning test
period. These other personnel may also assist in the collection of data and the preparation of the
draft MCC Commissioning Report. The only restriction is in the actual operation of the DMCC
during these commissioning tests.
As the tests are run, each MCC will monitor the results, and will notify the DMCC of any
anomalies that they observe. The DMCC will correct any deficiencies and schedule a repeat of the
appropriate test(s).
As the tests are completed, the DMCC will prepare a DMCC Commissioning Report; when that
report is ready, it will be submitted to the HMCC for review and completion.
Establishment of Initial and Full Operational Capability
Step D will start the operation of the DMCC at Initial Operational Capability (IOC), and then (if
all goes well) the DMCC will proceed to Full Operational Capability (FOC) at a scheduled date.
As specified in document C/S A.006 section “Establishment of Initial and Full Operational
Capability”, the FOC date is automatically set at the IOC date plus 90 days, or as agreed with the
Joint Committee prior to integration testing. The IOC phase can be extended by up to an additional
nine months, if problems are discovered during the operation of the MCC.
Note that one of the major differences of the operations of an MCC during the IOC phase is that it
will support only its own national RCCs in its declared Service Area. For a new MCC, the other
SPOCs in the declared Service Area will continue to be served by the MCC that was supporting
them before the new MCC was planned. As noted in document C/S A.006 section

![Image 1 from page 89](/images/cospas-sarsat/G-series/G010/G010_page_89_img_1.png)

![Image 2 from page 89](/images/cospas-sarsat/G-series/G010/G010_page_89_img_2.png)

5-15

“Recommissioning of a Previously Commissioned MCC”, if the upgraded MCC maintains an
“operational” status, it shall continue to distribute alert data to its associated SPOCs, unless the
associated nodal MCC determines that continued distribution poses a significant risk that the
associated SPOCs will not receive timely, reliable alerts. Since an extended period of such support
(in addition to its normal responsibilities as an MCC with its own Service Area) can impose a
significant hardship on the MCC that backs up the DMCC, the planned duration of the IOC phase
may be reduced in such a situation. (This is especially true if the re-commissioning was due to an
enhancement of the DMCC, and not to a failure of the existing DMCC system.)
The HMCC must confirm that the DMCC Ground Segment Provider has completed the formalities
necessary to become a participant in the Programme, and that the commissioning tests have been
successfully completed. The HMCC can then declare the DMCC at IOC and notify the other MCCs
that this new MCC is operational (at IOC). (If there are minor deficiencies, the HMCC may allow
the DMCC to go to IOC, as long as there is a plan to correct the problems before FOC is declared.)
During this IOC phase, the DMCC participates in all Ground Segment operations, but it is
restricted to supporting only its own national area in the declared MCC Service Area. The HMCC
directs the activity of the DMCC during this IOC phase and any problems that are detected with
the DMCC during this period should be reported to the HMCC.
Before declaring the DMCC at IOC, the HMCC sets a date for the advance of the DMCC to FOC.
Before that date, the HMCC will arrange, through its Representative to Cospas-Sarsat, to submit
the DMCC Commissioning Report to the Secretariat, for review and recommendation by the Joint
Committee and for approval by the Council, at the next suitable opportunity. When the date arrives,
and assuming that there have been no problems during the IOC phase, the DMCC will move to
FOC. The HMCC will notify all other MCCs of the change of status. All MCCs (including the
DMCC and HMCC) will re-configure as necessary so that the DMCC supports all the SPOCs in
its declared Service Area
If there are problems observed during the IOC phase, they must be corrected before the DMCC
can proceed to FOC. If the problems are not serious, they may be corrected during the IOC phase.
(This IOC phase may be extended, if necessary. However, the total duration of the IOC phase may
not be extended to be more than one year from the initial declaration of IOC.) If the MCC is not
able to transition to FOC at the end of the one-year period, the new MCC will be considered not
operational and will be documented as “under development”; the system should be repaired so that
it can pass the commissioning, and a new commissioning should be scheduled.
Note that, although the DMCC Commissioning Report may not be reviewed and approved
immediately, the DMCC will proceed to FOC as scheduled, as long as the HMCC is satisfied that
it has performed correctly during the IOC phase.
Limited Re-Commissioning of an MCC
Limited MCC re-commissioning is described in document C/S A.006 section “Recommissioning
of a Previously Commissioned MCC”.

![Image 1 from page 90](/images/cospas-sarsat/G-series/G010/G010_page_90_img_1.png)

5-16

5.3.2
Monitoring the National Ground Segment
The national ground segment of a Cospas-Sarsat Ground Segment Provider may include one or
more of:
• The national MCC and a backup MCC,
• Associated LUTs,
• Reference beacons and beacon simulators,
• Communications links.
In addition to these specific System components, the MCC is expected to be aware of the operation
of the entire Cospas-Sarsat System, and to report or otherwise respond to any anomalies in the
operation of any part of that System.
MCC Monitoring
An MCC is required to monitor all communications that it transmits or receives, to ensure that the
data is correctly received at the intended destination. The MCC is also required to maintain records
of all information that it receives and processes. Any anomalies in the processing or
communications of the data by the MCC are to be reported to the MCC operator.
In addition, document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”, identifies
several performance parameters to be monitored during the operation of an MCC. Some of these
are a part of the Cospas-Sarsat Quality Management System (QMS), whose regular monitoring is
required by the MCC specification (document C/S A.005), and others are MCC self-monitoring
parameters, whose monitoring is recommended but not required. The personnel at an MCC should
be aware of the state of each of these performance indicators and should take action if any of them
indicate a degradation in the performance of the MCC.
If the MCC is not performing all of its functions to the level required by the specification and the
other operational documents, the MCC manager should be notified, and take action accordingly:
• If possible, the anomaly should be corrected and the MCC returned to its full operational
capability as soon as possible.
• If the anomaly prevents the proper operation of the MCC, the appropriate backup
arrangements should be activated.
• If the anomaly cannot be corrected quickly, the associated nodal MCC (and any other
MCCs that may be affected by the anomaly) should be notified.
If the anomaly continues for any significant length of time, the MCC may be set to a
“Commissioned, not Operational (CNO)” status. The details for the process of determining when
an MCC is CNO, and for returning to normal operational status, are described in section 6.3.4 of
document C/S A.003 and in section 2.5 of document C/S A.006 (MCC Commissioning Standard).

![Image 1 from page 91](/images/cospas-sarsat/G-series/G010/G010_page_91_img_1.png)

5-17

The monitoring of the performance of an MCC is not restricted to the performance of the MCC
equipment (such as the computer system that performs much of the operational functions of the
MCC); it should also include the performance of the MCC personnel and the MCC
communications links.
LUT Monitoring
For a Ground Segment Operator that operates one or more Local User Terminals (LUTs), the MCC
is also expected to monitor the operation of those LUTs, including the communications links
between each LUT and the MCC. If any anomaly is detected in the performance of an associated
LUT, then it should be reported and addressed, in a manner similar to that recommended for an
MCC anomaly in section 5.3.2.1 above.
Monitoring other Ground Segment Components
A Ground Segment Operator that operates other equipment in the Cospas-Sarsat Ground Segment,
such as a reference beacon or beacon simulator, is also expected to monitor the operation of that
equipment, including any associated communications links. If any anomaly is detected in the
performance of any associated Cospas-Sarsat Ground Segment equipment, then it should be
reported and addressed, in a manner similar to that recommended for an MCC anomaly in section
5.3.2.1 above.
5.3.3
Communications Link Monitoring
Data communications facilities form a key part of the Cospas-Sarsat data distribution system.
These facilities may be private communications links, or they may be part of larger commercial
communications networks. They are generally designed for fully automatic operation, under the
control of the computer systems in the MCCs.
Communications Networks
As explained in section 4.4, document C/S A.002, “Cospas-Sarsat Standard Interface Description”
(the SID), includes a set of Annexes that describe the protocols that should be used with the
communications networks that are considered suitable for use.
For each of the different communications links that are supported by an MCC, the MCC
specification (document C/S A.005) defines the reliability level that it is expected to maintain
while it is in service. These reliability levels are stated in each of the following sections. The
document also specifies the volume of data that the MCC and the associated communications links
shall be capable of processing.

![Image 1 from page 92](/images/cospas-sarsat/G-series/G010/G010_page_92_img_1.png)

![Image 2 from page 92](/images/cospas-sarsat/G-series/G010/G010_page_92_img_2.png)

![Image 3 from page 92](/images/cospas-sarsat/G-series/G010/G010_page_92_img_3.png)

5-18

Communications Links with Associated LUTs
As noted above, the communications between an MCC and its associated national LUTs is
determined by the national Administration, as a matter of national prerogative. In fact, the primary
determinant is usually the distance between the systems.
If the LUT and MCC are located close together, then the link is usually a direct cable link, using
the Internet protocols between the two systems. If the distance is too far for a simple cable link,
then the choice of the communications facility is determined by the availability of the service. If
the Administration has a private communications network available, then that network will
probably be used. Otherwise, a commercial network (using the Internet protocols) is the most
likely choice for this link.
Although the SIT message formats that are described in the SID are not explicitly designed for
LUT to MCC communications, and are not mandatory, most LUT to MCC communications links
make use of these formats. The message formats may be extended to include variations on the SIT
formats, possibly with extra message data fields, to support the additional data that may be
available from the LUT (and of interest to the associated MCC).
The link between an MCC and each of its associated LUTs is required to be operational at least
99% of the time.
Communications Links with National RCCs
The communications between an MCC and its associated national RCCs is determined by the
national Administration, as a matter of national prerogative. Again, the primary determinant is
usually the distance between the systems.
If the MCC and RCC are located close together, then the link is usually a direct cable link, using
the Internet protocols between the two systems. If the distance is too far for a simple cable link,
then the choice of the communications facility is determined by the availability of the service. If
the Administration has a private communications network available, then that network will
probably be used. For aviation RCCs, the AFTN, which is available and supported by the national
aeronautical infrastructure, may be used. Otherwise, a commercial network (using the Internet
protocols) is the most likely choice for this link.
The SIT message formats that are defined in the SID are not mandatory for use with a national
RCC. However, the SIT 185 message format, which is officially defined specifically for use with
a foreign SAR Point of Contact (SPOC), contains most of the data that is of interest and of use to
the Search and Rescue personnel at an RCC. And the SIT 185 message format is not as fixed as
the other SIT message formats, so the contents of the message can be varied without violating the
message format described in the SID. In addition, the MCC has the software to generate these
messages for foreign SPOCs, so it is normally just a matter of configuration to use the same
software with a national RCC. As a result, most MCCs use some variants of the SIT 185 message
format to send incident alert data to their own RCCs.

![Image 1 from page 93](/images/cospas-sarsat/G-series/G010/G010_page_93_img_1.png)

![Image 2 from page 93](/images/cospas-sarsat/G-series/G010/G010_page_93_img_2.png)

5-19

The link between an MCC and each of its associated national RCCs is required to be operational
at least 95% of the time.
Communications Links with Foreign MCCs
The SID specifies the communications links between operational MCCs. It is mandatory (as
specified in document C/S A.005) that all MCCs use the networks and protocols that are identified
in the SID.
Because the cost of the service is normally well-defined, as a monthly price for a connection to the
Internet, and because the available Internet services are generally capable of the high data rates
that may provide the best service, most links between MCCs are carried over the Internet; in
particular, these links use the FTP/VPN protocol.
The links between MCCs require a backup service, to ensure that the communications will
continue to be available even if the primary link fails. This backup service may be a separate
Internet link (which must use completely separate cable links, to ensure that there is no potential
single point of failure), or it may be a separate AFTN link. In a few cases, where no other alternate
communications service is available, secondary communications service is provided by email
(which should use an independent communications link).
The link between an MCC and any other MCC is required to be operational at least 99% of the
time.
Communications Links with Foreign SPOCs
Although the System allows for bilateral agreements for different communications links and
protocols, most of the existing operational MCC-SPOC links follow the directions laid out in the
SID. The actual network that is used normally depends on the availability of the service at each
SPOC.
If the SPOC has Internet service available, and because the Internet link is already available at the
MCC, most MCCs prefer to communicate with their SPOCs over the Internet, using the FTP/VPN
protocol. However, if the Internet is not available at the SPOC, an AFTN link may be used.
The link between an MCC and each of its foreign SPOCs is required to be operational at least 95%
of the time.
Communications Links with SSAS Competent Authorities
The communications links between an operational MCC and the SSAS Competent Authorities is
determined by mutual agreement between the MCC and each Competent Authority. The actual
network that is used normally depends on the availability of the service at each facility.
If an Internet service is available, and because the Internet link is already available at the MCC,
MCCs may prefer to communicate with their SSAS Competent Authorities over the Internet, using

![Image 1 from page 94](/images/cospas-sarsat/G-series/G010/G010_page_94_img_1.png)

![Image 2 from page 94](/images/cospas-sarsat/G-series/G010/G010_page_94_img_2.png)

![Image 3 from page 94](/images/cospas-sarsat/G-series/G010/G010_page_94_img_3.png)

5-20

the FTP/VPN protocol. However, if the Internet is not available at the Competent Authority, another
link may be used.
The link between an MCC and each of its SSAS Competent Authorities is required to be
operational at least 95% of the time.
Communications Links with Return Link Service Providers
The links with a Return Link Service Provider (RLSP) are only relevant to MCCs that
communicate directly with an RLSP. See document C/S A.005 section “Data Communication
Links” for further information.
The link between an MCC and its associated RLSP is required to be operational at least 95% of
the time.
Communications Links with the Location of an Aircraft in Distress Repository
The communications links between an operational MCC and the Location of Aircraft in Distress
Repository (LADR) that is operated under the direction of the ICAO are only relevant to nodal
MCCs. See A.005 section “Data Communication Links” for further information.
The link between an MCC and the LADR is required to be operational at least 95% of the time.
Data Communications Monitoring
Each MCC is expected to monitor each of its communications links to ensure that the incident alert
(and other) messages are successfully received by the appropriate destination facility.
For any communications service that provides confirmation of successful transmission, the
sending facility should verify that the confirmation is correctly received after each message has
been sent.
As messages are received from other MCCs, the sequence numbers of the messages should be
verified, to ensure that no message has been lost in transmission. And every message that is
received must be validated, to ensure that the data is correctly encoded, according to the
specifications for the SIT message format and each of the Message Fields that are contained in the
message, according to the requirements of the SID.
If any message is not received correctly by the MCC, then the sending MCC should be notified of
the error and asked to re-transmit the message. The two MCCs should coordinate their verification
of the messages to ensure that the communications link is working correctly.

![Image 1 from page 95](/images/cospas-sarsat/G-series/G010/G010_page_95_img_1.png)

![Image 2 from page 95](/images/cospas-sarsat/G-series/G010/G010_page_95_img_2.png)

![Image 3 from page 95](/images/cospas-sarsat/G-series/G010/G010_page_95_img_3.png)

5-21

Communications Link Tests
The various communications links that connect the MCC to its associated LUTs, to other MCCs,
and to the different alert data recipients that it supports are all described in section 4.4.1 of this
Handbook.
Each of these communications links must be maintained in a reliable state, so that they will work
correctly whenever they are required. If the link is in relatively continuous use, then no further
testing may be required. However, for a link that is not frequently used, occasional testing is
required to ensure that it will always be available. The testing that is required for each SPOC
communications link is identified in C/S A.005 and described in section F.3 of this Handbook.
As long as there is operational message traffic over a communications link, the validation and
verification of the messages that are sent and received over that link is sufficient to confirm that
the communications are working correctly.
For any communications link that is not used on a regular basis, it is necessary to test the link. This
is particularly true of the links between an MCC and the SPOCs that it supports. In the nature of
Search and Rescue operations, it is possible that there may be no distress incidents, and therefore
no incident alert messages, over the course of a year. In any such case, the responsible MCC is
expected to generate one or more test messages to send to the SPOC, and to request confirmation
from the SPOC that the message has been correctly received. The reports of these communications
tests are included in the Status and Operations Report that the MCC sends to the Cospas-Sarsat
Secretariat each year for review by the Cospas-Sarsat Joint Committee.
From these reports, the Secretariat compiles a summary of the status of the SPOCs (and their
communications links) for presentation to the Joint Committee. After review, this summary may
be forwarded to ICAO and IMO for their information. These organizations, pursuing their interest
in and commitment to search and rescue, may take action to improve the quality of services that
can be provided by the RCCs involved.
If the receipt of the test messages to any SPOC is not confirmed as expected, the responsible MCC
should make other attempts to contact the SPOC, and to ensure that the SPOC and the associated
communications services are operating correctly. If the SPOC cannot be contacted and its correct
operation confirmed, then the MCC should make whatever effort is necessary to ensure that
incident alert data for the country in question will be responded to appropriately. This may require
the identification of a new SPOC. Where there is unusual difficulty in identifying a SPOC for a
particular region or nation, the MCC may request assistance from ICAO, IMO, or other appropriate
international organizations.
If no other effort leads to the successful identification of a SPOC that can receive and respond to
incident alerts, the MCC may have to deliver the alert to another RCC (probably in the State that
operates the MCC), and ask that RCC to follow through, according to its own operating procedures,
to ensure that the alert is dealt with appropriately.

![Image 1 from page 96](/images/cospas-sarsat/G-series/G010/G010_page_96_img_1.png)

5-22

5.3.4
Space Segment Monitoring
After each satellite of the Cospas-Sarsat Space segment is launched, it goes through a
commissioning evaluation, as described in the appropriate commissioning document (document
C/S T.004, C/S T.013, or C/S T.017, as listed in Table 2-6). Unlike the LUT and MCC
commissioning standards, these commissioning standards are not pass-or-fail tests.
Because the spacecraft of the Cospas-Sarsat Space Segment are satellites of opportunity, designed
for a different primary mission and donated by the Space Segment Provider for the use of the
System, the Cospas-Sarsat Programme does not produce any specification for the SAR payloads,
and there are no direct criteria for acceptance or rejection of the payloads. In addition. once the
satellite is in orbit, it cannot be returned for repair. And it cannot easily be replaced. So, the intent
of the commissioning of the spacecraft is to characterize its performance. This provides a
description and a baseline which can be used by the Cospas-Sarsat Ground Segment to manage
the processing of the data received through each spacecraft.
There are no explicit requirements for the monitoring of the Cospas-Sarsat Space Segment in the
MCC specifications (in C/S A.005) or in the other operational documents (A.001, A.002, or
A.003). However, each MCC receives and processes data that has passed through and been
processed by one or more of the components of the Space Segment; as a result, it has the
opportunity to review this data and to note when any anomalies occur. In addition, the MCC
personnel are in contact with the RCCs who use data from the Cospas-Sarsat System, and who
will notice any unusual or suspect data.
During the operation of the system, the Space Segment is monitored in various ways:
• The Space Segment Providers regularly monitor and test their spacecraft, using their own
LUTs and other specialized test facilities.
• The Quality Management System (QMS) requires every MCC to report certain data to its
associated nodal MCC, which analyses the data and reports on any anomalies that are
discovered during this analysis.
• The MCC self-monitoring, described in document C/S A.003, “Cospas-Sarsat System
Monitoring and Reporting”, may result in the detection and reporting of an anomaly in the
operation of one of the spacecraft of the Cospas-Sarsat Space Segment.
Whenever the staff at an MCC become aware of any anomaly in the operation of any part of the
Cospas-Sarsat System, they should investigate or report it to the Participating State that is
responsible for the component that may be causing the problem. If it is not clear which
component(s) may be at fault, then the problem may be reported to the associated nodal MCC for
further investigation. In cooperation with the nodal MCC, the MCC should ensure that the anomaly
is clearly pointed out to the responsible Participant and is dealt with appropriately.
When a nodal MCC is informed of a potential satellite outage, it will update the QMS status display
on the Cospas-Sarsat website to show the current status of the spacecraft involved. The nodal MCC
will also notify the Space Segment Provider who is responsible for that spacecraft. The Space

5-23

Segment Provider will then (in cooperation with the Ground Segment Provider who initially
reported the issue and the nodal MCC) perform whatever further analysis may be necessary to
identify the cause of the problem, and will determine what action is required to address the
problem.
The Space Segment Provider will notify the Ground Segment Providers, through a SIT 605 System
status message from its associated MCC, of the situation, and of the current status of the spacecraft.
The action that may be taken to address a spacecraft problem may be any of a wide range of
options. The Space Segment Provider may:
• Issue commands to the spacecraft, to change the configuration to bypass any component
that is not operating correctly.
• Issue commands to the spacecraft, to change the orbit to avoid a situation that may cause
the problem.
• Recommend changes to the Ground Segment processing to avoid or to correct the problem.
• Recommend a work-around which allows the Cospas-Sarsat System to continue to use the
spacecraft, possibly in a degraded mode.
• Determine that the problem is temporary and recommend that Ground Segment Providers
remove that spacecraft from their tracking schedules until the problem resolves itself.
• Determine that the spacecraft is no longer operational and remove it from the list of
operational Cospas-Sarsat satellites.
Whatever the action that is decided, the Space Segment Provider will notify the Ground Segment
Providers of the on-going status of the spacecraft and of any actions that are recommended to
address the issue.
When the issue is resolved and the spacecraft returns to normal operation, the Space Segment
Provider will notify the Ground Segment Providers, through another SIT 605 System status
message from its associated MCC, of the resolution, and of the current status of the spacecraft.
Once the spacecraft has been operating correctly for some period of time, the associated nodal
MCC will then update the QMS display on the Cospas-Sarsat website to show the return to
operational status.
- END OF SECTION 5 -

6-1

6.
FUNCTIONS OF AN MCC OPERATOR
For an MCC to fulfil its obligations in the Cospas-Sarsat System, the MCC operator must be able
to perform many functions.
Many of the functions that are required of an MCC operator, including many of those functions
listed in Annex G of C/S A.006, are described in the remainder of this chapter. These descriptions
are all at a general level; the details will vary according to the equipment available and the
procedures defined for the operation of any individual MCC.
For specific details of how an MCC operator should perform any individual function on the
available MCC equipment, the operator is referred to the equipment manuals that are supplied by
the vendor of the equipment that is used in their MCC.
Although the explanations below say that the MCC operator should perform many specific actions
in the cases described, the actual performance of these actions may be delegated to others:
•
the MCC System Manager,
•
another operator who is familiar with the recommended action,
•
another person designated by the Ground Segment Provider Administration,
•
a contracted support person or organization.
For each MCC, the local operational procedures should identify the appropriate person to take
action in each situation.
6.1
Communications with SPOCs
The MCC operator must be familiar with all of the SPOCs and RCCs that are served by this MCC,
and with the means that are available to communicate with each of these facilities. For each SPOC
or RCC, this may include any of the facilities described in the following paragraphs.
The MCC operator must be able to communicate by voice with the destination facility. This means
that the operator must have the necessary telephone numbers available. If the MCC employs a
translation service to communicate with personnel at other facilities, then the MCC operator should
be capable of using this translation service as needed. It is recommended that MCC operators have
basic English language skills.
The MCC operator must also be able to use any of the other means of communications that have
been agreed with each SPOC or RCC, which may include facsimile (fax) or email. For each such
link, the operator must have available the telephone number or email address of the destination
facility.

6-2

Section 4.4 of this Handbook describes the data communications links that may be used in the
Cospas-Sarsat data distribution system, and the interfaces that the MCCs have to support to use
these communications links. These links may also be used to send narrative text messages to the
personnel at the destination facility.
For all of these communications links, the MCC operator must be able to use the communications
equipment, both to send and to receive messages, and to generate and receive (and understand) the
information in a language that is compatible with the personnel at the destination facility.
When an incident alert message is to be sent to a destination facility, the MCC equipment will
automatically format the alert data, typically as a SIT 185 message (as explained in section 4.5.3
of this Handbook) and send this message to the destination facility. However, the MCC operator
must be able to provide any necessary support to the personnel at the SPOC or RCC. This may
include:
• Find the data associated with any specific incident alert, based on any of the information
listed in section 3.10 (“Information Archival and Retrieval”) of the MCC specification
(document C/S A.005). The search parameters will include the identification of the
destination facility, and may also include one or more of:
-
the date and time,
-
the geographic location,
-
the beacon identifier or its country code,
-
the identification of the vessel on which the beacon is carried.
• Find any specific message, based on any of the information listed in section 3.10
(“Information Archival and Retrieval”) of the MCC specification (document C/S A.005).
The search may be based on the destination facility and the range of times. Alternately, it
may be based on the direction of transmission (sent or received at the MCC) and any one
of:
-
the date and time,
-
the SIT format number,
-
the source or destination of the message,
-
the beacon identifier or its country code,
-
the identification of the vessel on which the beacon is carried.
The SPOC or RCC may ask for assistance interpreting the data in the incident alert message. For
example, a SPOC may ask why a particular type of alert (an initial alert, a confirmation alert, a
conflict alert, or a cancellation message) was generated and what this means for the beacon
incident. The SAR personnel may also want to know more about the reliability or accuracy of any
individual position estimate. While not required, it is helpful if the MCC operator is able to provide
advice and assistance to the Search and Rescue personnel in response to all such inquiries.

6-3

In particular, it is valuable if the MCC operator is able to provide assistance regarding the data
provided in the SIT 185 message, as described in section "Cospas-Sarsat Distress Messages" of
document C/S G.007, “Handbook on Distress Alert Messages for Rescue Coordination Centres
(RCCs), Search and Rescue Points of Contact (SPOCs) and IMO Ship Security Competent
Authorities”, including position data that can be found in section “Summary Guidance on the use
of position data in alert messages”.
The incident alert messages that are sent to SPOCs are normally in the SIT 185 message format,
unless the national Administration has selected a different format (such as WhatsApp). These
messages are specified in the SID (document C/S A.002) and they are described in document
C/S G.007 (RCC Handbook). They are not explained in this Handbook. However, many of the
data items that are included in these SIT 185 messages are also used in other message formats and
are described in various parts of this Handbook.
The SAR personnel may also be interested in the coverage available for a specified area of interest;
the coverage analysis described in section 6.13 of this Handbook addresses this type of inquiry.
6.2
Communications with other MCCs
The MCC operator must also be aware of the other MCCs with which their MCC may have to
communicate. For most non-nodal MCCs, this will be their nodal MCC. In addition:
• The operator at a nodal MCC must be able to communicate with all of the other nodal
MCCs and with any of the MCCs within their own DDR.
• The operator of an MCC in the Central DDR must be able to communicate with all of the
other MCCs in that DDR (including the nodal FMCC).
• If any bilateral agreements exist with other MCCs, the operator must be able to
communicate with those MCCs.
In addition to these explicit communications requirements, it is advisable that an MCC operator
should be able to communicate with any MCC whose Service Area is adjacent to their own Service
Area.
6.2.1
General Communications
As for the communications with the personnel at a SPOC, the MCC operator must be able to
communicate by voice with the other MCC. This means that the operator must have the necessary
telephone numbers available. If an MCC employs a translation service to communicate with
personnel at other facilities, then the MCC operator should be capable of using this translation
service as needed. The MCC operator must also be able to use any of the other means of
communications that have been agreed with the other MCC, which may include facsimile (fax) or
email.

6-4

For all of these communications links, the MCC operator must be able to use the communications
equipment, both to send and to receive messages.
6.2.2
Narrative Messages
A narrative message is essentially a message that contains a free-form block of text for the
information of the operator at the receiving facility. It is formatted to the extent that it includes the
header and trailer information that is necessary to route the SIT message through the data
distribution system and that it is restricted to the character set defined in the SID (see section B.1
of this Handbook). Otherwise, the contents of the message can be laid out in any way that the
operator desires. A more detailed description of the narrative message format is provided in section
A.7.3 of this Handbook, and further information is available in section B.7 of this Handbook.
These narrative messages are intended to be read by a human at the receiving facility; they are not
designed for automated processing.
The sample narrative message in Figure 6.1 is a test message that could be sent to request that the
recipient acknowledge receipt of the message, to verify that the communications link has
performed successfully. Additional samples are provided elsewhere in this document.
Narrative messages are normally entered by the operator, using the capabilities provided by the
computer system at the MCC. However, there are a few types of narrative message that may be
generated automatically by the MCC computer.
/00087 00000/7010/20 098 1404
/915/5030
/
FROM: ARMCC
TO: AUMCC
THIS IS TEST MESSAGE FROM ARMCC TO AUMCC. PLEASE ACKNOWLEDGE
BY DIRECT FTP VPN AND AFTN LINK.
BEST REGARDS
ARMCC OPERATOR.
QQQQ
/LASSIT
/ENDMSG
Figure 6.1: Sample Narrative Message
This is a sample of a narrative message to verify the correct operation of the communications link
between two MCCs.

6-5

6.2.3
System Status Messages
A system status message should be used in any situation where the status of some part of the
System has changed and the new status is likely to affect other MCCs. It is intended to be read by
a human at the receiving facility; it is not designed for automated processing.
Many system status messages are generated automatically by the MCC computer, to report on
anomalies in the status of some component of the system, as detected by the MCC computer.
However, a system status message may also be entered by the operator, using the capabilities
provided by the computer system at the MCC.
The sample system status message in Figure 6.2 is a routine message to notify all MCCs when an
MCC is replaced by an operational backup. (More information about this kind of situation is
provided in sections B.8 and D.1 of this Handbook.) Additional samples of system status messages
are provided elsewhere in this document.
FROM: FMCC
TO: ALL MCCs
SUBJECT: ITMCC BACKUP
1. ITMCC IS NOT OPERATIONAL FROM 0725 UTC DUE TO MAINTENANCE
2. THE FMCC HAS ASSUMED THE BACKUP AND DUTIES OF THE ITMCC AT 1200 UTC
3. MCCS ARE REQUESTED TO TRANSMIT ALL TRAFFIC FOR THE ITMCC TO FMCC.
4. CENTRAL DDR MCCS ARE INVITED TO CONFIRM RECEIPT OF THIS MESSAGE BY
SENDING AN ACKNOLEDGE MESSAGE TO THE FMCC AFTER THE CONFIGURATION CHANGES
ARE MADE.
5. ITMCC WILL INFORM WHEN IT RESUMES THE NORMAL OPERATIONS.
6. FMCC COMMUNICATION ADDRESSES:
AFTN LFIAZSZX
FAX: +33-561 274 878
PHONE: +33-561 254 382
BEST REGARDS
FMCC
Figure 6.2: Sample System Status Message
This sample message shows the announcement of an MCC assuming the backup of a not operational
MCC that is not a nodal MCC.
6.2.4
SIT Messages Embedded in Narrative Messages
The Cospas-Sarsat System documents are generally intended to describe a System that is complete
and coherent. That is, all parts of the System work together to meet the same specifications.
However, in the real world, it is not always possible to maintain such a complete level of
consistency. Some parts of the System may have been upgraded while other parts have remained
at a previous level of operation. In such cases, it is often necessary to provide a work-around, to
allow the two parts to continue to operate together during the interim period before all components
of the System have achieved the full level of compatibility with the specifications.

6-6

One method that is used to allow such a level of inter-operability of components that are at different
levels of implementation is to take a message that has been structured according to a newer SIT
message format specification and to encapsulate it in a narrative message (SIT 915) format. This
process is described in more detail in section D.5 of this Handbook. That section also explains
some of the circumstances where this work-around is recommended.
6.3
Monitoring the System
As noted in section 5.2.3 of this Handbook, an MCC operator must be able to monitor the MCC
itself and the other parts of the Cospas-Sarsat System that are linked to it, to ensure that they are
functioning correctly. Typically, a computer-based MCC will raise warnings and alarms to indicate
any problems that need to be addressed. An MCC operator must be able to respond to any warnings
or alarms raised by the MCC.
Section 5.2.3 of this Handbook describes some of the checks that are recommended to enable the
operator to verify the operation of the MCC and of the Cospas-Sarsat System. Some additional
checks are described in the remainder of this section.
In addition to this monitoring, the MCC operator should maintain a general awareness of the status
of the System.
6.3.1
External Systems Monitoring
The operator can verify the operation of external systems, including the communication links to
them. The first step is to determine the time of the most recent communications on the links
between the MCC and:
• Each LUT associated with the MCC,
• Each other MCC that communicates directly with the MCC,
• Each RCC or SPOC that is supported by the MCC,
In each case, if there have not been any recent communications, the operator should determine
why this is the case.
The most likely cause, of course, is that there has been no data to be sent. In this situation, the
operator should initiate communication checks to verify that the communications link and the
system at the other end of the link are performing as required. If, on the other hand, the lack of
communications is due to a problem with the communications link or with the destination system,
the operator should start an investigation to determine what the problem is and to resolve that
problem.
The communications link testing is described in more detail in section F.3 of this Handbook.

6-7

6.3.2
Reference Beacon Monitoring
An MCC that is associated with an administration that is responsible for the operation of a system
reference beacon should verify that the signals from the reference beacon are regularly detected
and reported to the MCC.
Many reference beacons are monitored under the provisions of the Cospas-Sarsat Quality
Management System (QMS); however, even those reference beacons which are outside the scope
of the QMS verification should be monitored by the operator of the beacon. If there are any
anomalies in the data that is received from the beacon, then the associated MCC should report
them to the other Ground Segment Providers and should investigate the cause of the anomaly, as
necessary, and problems should be corrected.
6.4
MCC Backups
Each MCC is a vital part of the Cospas-Sarsat data distribution system. Therefore, if any MCC
fails, it is essential that the system be re-configured to ensure that the data distribution system
remains intact, and that all incident alert messages will be distributed to the correct final
destination. Document C/S P.011, “Cospas-Sarsat Programme Management Policy” and the MCC
specification (document C/S A.005) place specific requirements on the time allowed to switch to
the operational backup: “the capability of an MCC to continuously deliver alert messages shall not
be interrupted for longer than one hour”. To ensure that this requirement is met, the MCC
specification further requires that “all affected MCCs shall implement backup procedures within
30 minutes of notification”.
Some Ground Segment Providers include a second set of MCC equipment as a part of their
contribution to the data distribution network. If an MCC that has such an internal backup capability
fails, then the MCC operator must be able to change to the internal backup capability quickly as
soon as it may be required. This switch-over may be done directly by the MCC operator or it may
be done by calling in support services.
If the MCC cannot operate, and if the internal backup facility is not available (or not working), the
MCC operator must then ask to be backed up by its backup MCC. Typically, such a request would
be made by telephone; alternately, it could be done by sending a narrative message to the backup
MCC. Once backed up by another MCC, the MCC operators (at both the failed MCC and the
backup MCC) must know the local procedures to deal with beacon alert data sent. For example,
the beacon alert data might be sent as SIT 185 messages by fax or other means from the backup
MCC to a facility, identified in the backup plan, which can distribute alerts to the supported
SPOCs. Alternately, the backup MCC may have to be re-configured to automatically distribute the
data to the SPOCs and RCCs of the failed MCC. Whatever the arrangement, all beacon alert data
received by the backup MCC must be forwarded (manually or automatically) to the responsible
SPOC or RCC.

6-8

When an MCC is backed up, either by an internal facility or by another MCC, the backup MCC
will send a SIT 605 message to inform all MCCs of the situation. (See the sample messages in
Figure B.1, Figure B.2, and Figure B.3.)  In most of these cases, most MCCs do not need to change
any communications. Only those MCCs that are directly linked to the failed MCC will have to
make changes, to ensure that the data is sent to the correct backup facility. However, the MCC
operators must be aware of the impact of any MCC backups and be able to change communications
as and when necessary.
If a nodal MCC fails and is being backed up, the backup MCC will send a SIT 605 message to
notify all MCCs of the failure and the backup arrangements that are in place. The operator of each
associated MCC must change the configuration of their communications to ensure that all beacon
alert data is sent directly to the nodal backup MCC.
When the failed MCC is restored to full operational capability, it will send a SIT 605 status
message to notify all MCCs of this change. (See the sample messages in Figure B.4 and Figure
B.5.) At this time, the operators of all affected MCCs must restore their system to its normal
operating configuration.
A more comprehensive explanation of the backup requirements for an MCC is provided in
section D.1 of this Handbook.
6.5
Communications Support
The Cospas-Sarsat data distribution system is essentially a communications network; as such, the
communications facilities in that network are absolutely necessary for the correct operation of that
system. If any communications link fails, there has to be a quick and efficient method of
maintaining the network while the failed component is repaired and brought back into service.
The communications services that are described in the SID (document C/S A.002) and that are the
primary means of data communications through the network are all basically reliable services that
include their own internal routing capabilities to by-pass individual failures within the network.
And each MCC is expected to maintain two separate communications links to any other MCC with
which it communicates. However, it can still happen that an MCC is unable to successfully
communicate with another MCC or with an RCC or SPOC.
If a single communications link (e.g., FTP/VPN) is lost for all MCC communications, the MCC
should send a narrative message (SIT 915) or a system status message (SIT 605) to notify other
MCCs of the problem, and to request that they use the alternate communications link for all
messages until the problem has been resolved. A sample of such a message is shown in Figure 6.3.
In this example, because the AUMCC is a nodal MCC that communicates with many other MCCs,
the message is sent as a system status message (SIT 605), so that all MCCs will be aware of the
situation.

6-9

As another example, suppose that an MCC uses AFTN to communicate with a SPOC and has no
alternate means of communication with that SPOC. In this case, if the AFTN fails, the MCC will
not be able to send incident alert messages to that SPOC.
When such a failure occurs (or more generally, when an MCC is not able to communicate with a
SPOC by any designated means), the MCC should request another MCC (via a SIT 915 message,
voice communications or other available means) to assume responsibilities to deliver messages to
the affected destination, per previously agreed backup procedures. Such backup procedures may
require that the assisting MCC perform a full backup of the failed MCC. Notification to other
MCCs would be performed per the agreed backup procedure. While the backup is in place, the
MCC should investigate the cause of the problem, and work to restore the normal communications
as soon as possible.
Once it is understood that the MCC has lost all communications facilities with another MCC, the
MCC should request another MCC (via a SIT 915 message, voice communications or other
available means) to assume responsibilities to deliver messages to affected destinations, per
previously agreed backup procedures. Such backup procedures may require that the assisting MCC
perform a full backup of the failed MCC. Notification to other MCCs would be performed per the
agreed backup procedure.
The sample message, in Figure 6.3, is a notification from the Australian MCC of a failure of its
primary communications link (FTP/VPN), with a request that other MCCs use the alternate
communications link (AFTN) in place of that failed link.
/85324 00000/5030/20 138 0125
/605/5030
/FROM  : AUMCC
TO   : ALL MCCS
SUBJECT : COMMUNICATIONS FAILURE
1. FTP WITH THE AUMCC IS CURRENTLY UNAVAILABLE.
2. PLEASE CHANGE COMMUNICATIONS TO USE AFTN WITH AUMCC.
SORRY FOR ANY INCONVENIENCE,
AUMCC
QQQQ
/LASSIT
/ENDMSG
Figure 6.3: Sample Notification of Communications Failure
This is a sample of a system status message that might be sent from an MCC to notify other MCCs
of a failed communications link and to request that they implement the appropriate backup
arrangements.

6-10

In the event of a complete failure of all communications services to an MCC, the MCC is
effectively out of service, and the appropriate backup arrangements will be required.
6.6
Resending a Missing Message
Every message from an MCC to a destination (MCC or RCC/SPOC) has a sequential message
number. When a destination receives a message from an MCC, it should check that the message
number is in sequence. If not in sequence, the destination knows that there is a problem with the
messages sent from the MCC.
For example, the AUMCC sends a message to the USMCC with message number 34267. If the
previous message from the AUMCC to the USMCC was message number 34265, the USMCC
operator knows that message 34266 from the AUMCC is missing. The USMCC operator should
then investigate and may request the AUMCC that the missing message be re-transmitted.
The resend request can be in a narrative message (as in Figure 6.4), or it may be a voice request
over the telephone If an MCC receives a message that is out of sequence, then the operators of
both MCCs (the originating MCC and the destination MCC) should coordinate to investigate the
reason for this anomaly. There are a number of obvious possibilities:
• A software failure in the originating MCC may have cause the wrong sequence number to
be placed in the message.
• A communications failure may have caused a previous message (or messages) to be lost or
corrupted. This failure may have occurred in:
-
the communications interface in the transmitting MCC,
-
the communication network hardware or software,
• A communications interface failure in the transmitting MCC may have caused the message
number in the current received message to be corrupted.
• A software failure in the receiving MCC may have caused the receiving MCC to incorrectly
report an anomaly when the message was actually received in the correct sequence.
Regardless of the cause of the problem, the MCC operators should ensure that any messages that
have been missed will be sent again.
If any message has been missed, the operator at the receiving MCC should request that the message
be re-transmitted. The resend request can be in a narrative message (as in Figure 6.4), or it may be
a voice request over the telephone. The key information that will be required by the originating
MCC is the message number of the original message(s).

6-11

/81193 00000/5030/20 098 1326
/915/5630
/FROM: AUMCC
TO: SIMCC
SUBJ: MISSING MESSAGE
PLEASE RESEND MESSAGE 41534 TO THE AUMCC.
REGARDS
AUMCC
QQQQ
/LASSIT
/ENDMSG
Figure 6.4: Sample Message Re-Transmission Request
This is a sample of a narrative message that might be sent from an MCC to request that another
MCC re-send a message that was not received in the expected sequence (possibly due to a failed
communications link).
The MCC operator(s) at the originating MCC must be able to find all of the original messages and
have them re-transmitted to the appropriate destination.
As specified in document C/S A.002, the message number field (MF \#10) contains two separate
message numbers. The first number is the message sequence number that is computed when the
message is formatted, and the second number is used to identify the original message number of a
previously sent message. Figure 6.5 contains a sample of a message that has been re-transmitted,
with the new message number in the first part of the MF \#10 and the original message number in
the second part of MF \#10.

6-12

/09925 09922/2470/20 137 1418 FTP
/915/2270
FM ITMCC
TO FMCC
SUBJECT: LEOLUT LOCATION ACCURACY CONFORMITY STATUS MESSAGE.
IN ACCORDANCE WITH COSPAS SARSAT C/S A003 PARA 2.5.4.3 ITMCC HAS
RESUMED THE DISTRIBUTION OF DOPPLER SOLUTION DATA FOR COMBINATION LEOLUT
2471 AND
SATELLITE S13.
BEST REGARDS
ITMCC
QQQQ
/LASSIT
/ENDMSG
Figure 6.5: Sample Re-Transmitted Message
This is a message that has been re-transmitted, with the message number field containing both the
original message number and the new message number.
6.7
Suppressing Beacon Alerts
Following the rules specified in the Cospas-Sarsat Data Distribution Plan (the DDP, C/S A.001),
an MCC will normally send every incident alert that it receives to the appropriate destination,
whether that destination is another MCC or a SPOC or RCC. However, that destination may not
wish to continue receiving such alert messages indefinitely. The MCC Operator shall be able to
suppress (or enable) alert data transmission for a particular beacon when requested to do so by an
alert data recipient.
There are many reasons why an alert data recipient may wish to suppress the reception of alert
messages from a particular beacon, such as:
• The beacon activation has been determined to be a false alert, and no distress incident is
taking place.
• The beacon has been located and rescue personnel have contacted the person(s) in distress;
no further information is required from the Cospas-Sarsat System.
• The beacon has been located and the person(s) in distress have been rescued, but it was not
possible to recover the beacon and turn it off.
• The beacon is being used for a test, and no distress incident is involved.
• A test is planned; again, there will be no distress involved.

6-13

In any of these situations, and especially when the MCC (or SPOC) is busy with other distress
incidents, they may not wish to be distracted by reports from a beacon that is not involved in a real
emergency.
After a beacon has been identified for suppression of alerts, it may become necessary to resume
the transmission of those alerts. For example:
• A beacon that had been located may be lost. If the weather has turned bad, or if the wind
has risen at sea, the beacon may not be in the same location, or it may not be easy for the
rescue personnel to find.
• A search aircraft that located the beacon may have run low on fuel and have to return to its
base before the rescue can be continued.
• The conductors of a test may wish to receive more data about the test beacon(s) from the
MCC.
In any of these (or similar) situations, the beacon is marked for transmission.
In all of these cases, the MCC that is requesting the suppression or transmission of incident alert
messages sends a message to the other MCCs to notify them of the situation, and to request the
appropriate action. Depending on the situation, and the number of MCCs to whom the request has
to be sent, this may be done in a narrative (SIT 915) or a system status (SIT 605) message. The
narrative message in Figure 6.6 is an example of a message that might be sent to notify another
MCC when it does not want to receive any more incident alert messages for a specified beacon. In
this case, as explained in the message, the alert has been confirmed as a false alert.

6-14

/00460 00000/4770/20 099 0255
/915/5030
/
FROM: HKMCC
TO: AUMCC
SUBJECT: SUPPRESSING SIT 915 MEOSAR ALERT MSGS TO THE HKMCC
AUMCC REF NO : 74948
HEX ID : 3384E502C2FFBFF
COUNTRY : 412/CHINA
THE HKMCC WOULD LIKE TO ASK FOR THE AUMCC TO SUPPRESS THE CONTINUOUS
TRANSMISSION OF ALERT MESSAGES FOR THE ABOVE BEACON ACTIVATION
TO THE HKMCC.
THE ALERT WAS CONFIRMED AS FALSE ALERT.
THANK YOU FOR COOPERATION
REGARDS,
HKMCC OP
QQQQ
/LASSIT
/ENDMSG
Figure 6.6: Sample Message to Request Suppression of Beacon Alerts
This is a sample of a narrative message that might be sent from an MCC to notify another MCC that
it no longer wishes to receive alert data from the specified beacon.
Figure 6.7 then shows the response, which acknowledges the request and confirms that the
transmission of alerts for the specified beacon will no longer be sent to the MCC that had requested
suppression of the alerts in Figure 6.6.
/75821 00000/5030/20 099 0302
/915/4770
/FROM: AUMCC
TO: HKMCC
SUBJECT: HEX ID 3384E502C2FFBFF
THE ABOVE BEACON HAS BEEN SUPRESSED TO THE HKMCC
REGUARDS
AUMCC
QQQQ
/LASSIT
/ENDMSG
Figure 6.7: Sample Message to Confirm Suppression of Beacon Alerts
This sample narrative message shows the response to the request in Figure 6.6.

6-15

An MCC operator may also request that the continued transmission of alerts be resumed for a
beacon, by sending a system status message to identify the beacon and to notify all MCCs that this
continued transmission is desired.
6.8
Quality Management System Messages
Document C/S P.015, “Cospas-Sarsat Quality Manual”, describes the Quality Management
System (QMS) that is used to ensure that the System maintains the quality standards that are
essential to such a critical operation.
The data distribution system is required to support the exchange of messages in support of the
QMS:
• Alert data for designated reference beacons is sent by all MCCs to their associated nodal
MCC, in the format defined in documents C/S A.002 and C/S A.003, as explained in
ANNEX B of this Handbook. This process is specified in the DDP (document C/S A.001)
and explained in ANNEX A of this Handbook. The format that is normally expected for
that type of data, as defined in the SID (document C/S A.002) and as explained in ANNEX
B of this Handbook, is used to transmit this QMS data.
• Each nodal MCC updates the status pages on the Cospas-Sarsat web site to inform all
MCCs (and the Secretariat and other interested organizations) of the current status of the
system in its DDR. As of 2023, this is done manually. As a system enhancement, nodal
MCCs will have the capability doing this by sending an XML file to the QMS Automated
Reporting System (QARS), as described in Annex J (“QMS Automated Reporting
System”) of document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”. The
format of the XML file is described in section J.2 (“XML Format for QMS and Space
Segment Status Report”) in Annex J of C/S A.003.
• The nodal MCC notifies any Ground Segment Provider whose contribution to the Cospas-
Sarsat Ground Segment is not meeting the relevant criteria. This is done by sending a
narrative (SIT 915) message to the MCC of that Ground Segment Provider. Section B.8.5
of this Handbook contains examples of such notification messages.
• The nodal MCC notifies any Space Segment Provider whose contribution to the Cospas-
Sarsat Space Segment is not meeting the relevant criteria. This is done by sending a
narrative (SIT 915) message to the MCC of that Space Segment Provider. The format of
such a notification message will be similar to the format used to notify a Ground Segment
Provider, as illustrated in the examples in section B.8.5 of this Handbook.
• The MCC of the Space Segment Provider sends a system status message to all MCCs to
inform them of the updated status of the equipment. A standard message format for this
notification is provided in Figure 5-4 (“Standard Message for Reporting a Spacecraft
Anomaly”) in section 5.2 (“Status of Space Segment”) of the DDP (document C/S A.001).
• The nodal MCC requests the MCC of a Ground Segment Provider to investigate an
identified issue when the relevant QMS criteria are not met. This is done by sending a

6-16

SIT 915 narrative message to the MCC associated with the failed equipment or a SIT 605
message to all MCCs. The templates for these messages are listed in Table  in this
Handbook.
• The nodal MCC notifies all MCCs when data from a particular component (or combination
of components) is being suppressed because it does not meet the required standards. A
system status message (SIT 605), such as the sample message shown in Figure B.13, is
used to send this notification. This message also requests that the MCC associated with the
failed equipment suppress associated (Doppler or DOA) position data.
• If a SIT 605 message was sent for a failed component, the nodal MCC notifies all Ground
Segment Providers when the failure has been resolved, and, as relevant, that data from that
component (or from a combination that includes that component) can now be distributed
through the System again. Another system status message (SIT 605), such as the sample
message shown in Figure B.14, is used to send this notification.
An MCC operator should be aware of the current status of the Cospas-Sarsat System at all times.
This is done by observing the system status and narrative messages that are received at their MCC.
The operator can also check the current status of the System by looking at the status pages on the
Cospas-Sarsat web site:
• On the professional web sub-site, select the <System> tab and then click on <Availability
Tables (QMS)> under <System Monitoring>.
• Scroll through the status tables on the display.
• Alternately, request a specific status display:
-
Select the Quality Monitoring System type,
-
Select the DDR.
• Review the status of the selected item.
The page also allows the operator to select the option to export the display in a printable format,
to a printer or to a Portable Document Format (.pdf) file. Figure 6.8 contains an example of the
display that is available from this web page.

6-17

Figure 6.8: Sample QMS Status Display
This is a sample of the System status display (retrieved in printable format) that is available on the
Cospas-Sarsat web site.
6.9
Beacon Registration Requests
When an incident alert message is received at an RCC or SPOC, the SAR technicians there will
usually want as much information as possible about the distress beacon that initiated the alert. A
major source of such information is the beacon registry, where the beacon should have been
registered.
A request for beacon registration information may occur as follows:
• The RCC or SPOC asks the destination MCC, from which they received the incident alert,
for more information about this beacon. This may be a digital message, or it may be a
verbal request by telephone. (Note that the alert message sent to the RCC or SPOC may
contain:

![Image 1 from page 115](/images/cospas-sarsat/G-series/G010/G010_page_115_img_1.png)

6-18

o relevant beacon registration information, if the MCC has registration information
for the subject beacon ID, or
o relevant beacon registry point of contact information, enabling the RCC or SPOC
to request registration information directly from the registry administrator or, if
beacons for the associated country code are registered in the C/S International
Beacon Registration Database (IBRD), enabling the RCC or SPOC to retrieve
registration information directly from the IBRD.
• The destination MCC retrieves the country code from the beacon message and identifies
the supporting MCC, in whose Service Area that country is.
• The destination MCC sends a request (in a narrative message) to the supporting MCC.
o If the destination MCC is also the supporting MCC, this step is not required.
o If beacons for the associated country code are registered in the Cospas-Sarsat
International Beacon Registration Database (IBRD), the destination MCC may
retrieve the registration information directly from the IBRD.
• The supporting MCC requests the beacon registration data from the country of registration.
The request must specify the beacon identifier:
-
A fifteen-character hexadecimal identifier for a first-generation beacon (FGB) or a
second-generation beacon (SGB),
-
A twenty-three-character hexadecimal identifier for an SGB.
This may be in the form of a data retrieval request directly to the beacon registration
database, a narrative message or a voice request to the holder of the registry, or any other
form that is acceptable to both parties to this exchange.
• The beacon register returns the information about the beacon.
• If the beacon is not registered, then this information is returned to the requesting party,
usually in the form of a narrative message.
• If the beacon is registered, then the supporting MCC sends the information from the register
to the destination MCC, formatted into a SIT 925 message as defined in the SID (document
C/S A.002).
• The message is sent to the requesting agency (RCC or SPOC).
This process is straightforward. However, there are exceptions.
The beacon may have been registered in the wrong database. This is not supposed to happen, but
it does occur occasionally. The MCC operator with some experience in the region may know of
another country that might hold this data, and re-direct the request to that country’s registry. If the
request does find the beacon, then the process can continue as above.
When a beacon design is type-approved, some information that will apply to every beacon that is
built to that design is recorded on the Type-Approval Certificate (TAC). For an SGB, that

6-19

information is stored in a database by the Secretariat; it is also sent to all MCCs (in a SIT 927
message). Each MCC maintains its own internal database of SGB TAC information, which it
updates each time it receives new information. The MCC can then retrieve that data and include it
in a SIT 985 message that is sent automatically with the incident alert message.
Figure 6.9 contains a sample narrative message that requests the beacon registration data for the
beacon whose identifier is specified in the message.
/51029 00000/2270/20 110 0542
/915/5030
/FM FMCC COSPAS-SARSAT TOULOUSE
TO AUMCC
FMCC REF NO 173065
HEXACODE (BEACON ID) : 3EF4957FBF81FE0
REF 406 BEACON : 76543, COUNTRY : 503/AUSTRALIA
LAT:06 57.7S, LONG:065 48.3E
A 406MHZ DISTRESS BEACON HAS BEEN LOCATED IN FMCC SERVICE AREA.
PLEASE SEND US AVAILABLE REGISTRATION INFORMATION FOR THIS BEACON ID
THANKS FOR COOPERATION.
FMCC.
QQQQ
/LASSIT
/ENDMSG
Figure 6.9: Sample Message to Request Beacon Registration Data
This is a sample of a narrative message that might be sent to an MCC to request the information held
in the beacon registry of the nation whose country code is encoded in the beacon identifier.

6-20

/71472 00000/3660/20 100 0657
/925/5030
/3EF4957FBF81FE0
/
BEACON ID: 2DC4000000FFBFF
**** BEACON REGISTRATION DATABASE INFORMATION ****
OWNER: ANONYMOUS OWNER
1234 LOCAL DRIVE       TEL 1: HOME 0123456789
HOME CITY         CA   TEL 2: WORK 1234567890
98765   USA            TEL 3:
EMAIL:
CONTACTS: JOHN DOE          JANE DOE
TEL 1: HOME 0123456789     TEL 1: HOME 0123456789
TEL 2:                       TEL 2: WORK 1234567890
VESSEL NAME: SUNKEN
TYPE: SAIL 1 Masts             LENGTH OVERALL (FT):  36
COLOR: BLUE/WHITE           CAPACITY:   8
RADIO CALL SIGN:             REGISTRATION NO: CF12345P
RADIO EQP: VHF               INMARSAT NUMBER:
CELLULAR NUMBER: 2345678901
NUMBER OF LIFE BOATS:   0      NUMBER OF LIFE RAFTS:   0
HOME PORT PRIMARY SRR: PACAREA    SECONDARY SRR:
HOME PORT: MARINA NAME           SAN FRANCISCO        CA
MANUFACTURER: XXX           MODEL NUMBER: ABC-12
ACTIVATION TYPE: CAT2 (MANUAL)
BEACON CONTAINS SVDR: NO
DATE FIRST REGISTERED: 02 JUN 1999  DATE REG EXPIRES: 02 JUN 2001
DATE LAST UPDATED: 02 MAY 2001
REMARKS:
SPECIAL STATUS:           SPECIAL STATUS DATE:
SPECIAL STATUS INFO:
QQQQ
/LASSIT
/ENDMSG
Figure 6.10: Sample Message to Report Beacon Registration Data
This is a sample of a beacon registration data message that might be sent from an MCC in response
to a request for beacon registration information. The details of exactly what registration data is
available will depend on the beacon registry and the data that was entered by the beacon owner.
Figure 6.10 contains the response to that request: the information that was retrieved from the
beacon register entry for that beacon. Figure 6.11 shows a different response: a narrative message
to say that the beacon was not registered. However, it does provide some information about
previous detections of the same beacon. See also “Sample Message for SIT 925” and “Sample
Message for SIT 985 SGB Characteristics Based on TAC Number” in document C/S A.002.

6-21

/85498 00000/5030/20 110 0600
/915/2270
/3EF4957FBF81FE0
/FROM: AUMCC
TO: FMCC
SUBJECT: BEACON WITH HEX 3EF4957FBF81FE0
PLEASE SEE BELOW INFORMATION FROM JRCC AUSTRALIA REGARDING BEACON
WITH HEX ID 3EF4957FBF81FE0
REGARDS
AUMCC OPERATOR
SUBJ: BEACON HEX ID: 3EF4957FBF81FE0
INCIDENT: 2020/2703
1. JRCC AUSTRALIA HAS CHECKED OUR REGISTRATION DATABASE FOR
AUSTRALIAN CODED BEACON HEX ID 3EF4957FBF81FE0 AND IT IS
UNREGISTERED.
2. THIS BEACON HAS BEEN DETECTED IN THE SEYCHELLES ON TWO PREVIOUS
OCCASIONS, 0N 05MAR20 AND 10APR20.
3. THIS ADVICE HAS ALSO BEEN CONVEYED BY EMAIL TO MRCC PORT BLAIR AND
IDMCC
4. WE ARE UNABLE TO PROVIDE ANY FURTHER INFORMATION ON THIS BEACON
BEST REGARDS,
JRCC AUSTRALIA
QQQQ
/LASSIT
/ENDMSG
Figure 6.11: Sample Message to Report No Beacon Registration Data
This is a sample of a narrative message that might be sent from an MCC to indicate that no
registration data is available, in response to a request for beacon registration information.
6.10
System Data Updates
As explained in section 4.3.5 of this Handbook, the satellite orbital elements and the spacecraft
calibration data are included in the System Data that is distributed through the MCC network.
The satellite orbital elements define the orbital path that the satellite follows around the Earth.
They are essential to the solution processing that produces the independent (Doppler or Difference
of Arrival) locations in the LEOSAR and MEOSAR systems, respectively. Although they are not
essential for the GEOSAR processing, some GEOLUTs use the GEOSAR satellite orbital elements
to improve the accuracy of the frequency measurements for each beacon signal that is received.

6-22

The satellite orbital elements are also used to determine the satellite footprint, for use in the
validation of the location data received by the MCC. See section A.6.6 of this Handbook for a
more comprehensive explanation of the satellite footprint validation. To support this footprint
check, each MCC should maintain a copy of every set of satellite orbital elements, whether or not
it has an associated LUT that may require that data.
The following sections describe the distribution of the System Data through the Cospas-Sarsat data
distribution system. However, in many cases, this data is also available from other sources. Table
6-1 contains a list of web sites that maintain current orbital elements for many of the satellites that
comprise the Cospas-Sarsat Space Segment.
Table 6-1 – Sources of Satellite Orbit Data
The web sites listed in this table provide orbital elements for the satellites of the Cospas-Sarsat Space
Segment.
Title
Link
Comments
Celestrak 1
https://www.celestrak.com/NORAD/elements/
Most of the
Space Segment
European GNSS Service
Centre (GSC) 2
https://www.gsc-europa.eu/system-service-
status/constellation-information
Galileo satellite
data
Notes:
(1)
An independent (non-Government agency) web site.
(2)
Operated by the European Global Navigation Satellite Systems Agency.
6.10.1 LEOSAR Orbital Elements
The orbital elements for each LEOSAR satellite are distributed through the MCC network to all
MCCs regularly, typically every business day, by each of the Space Segment Providers. These
elements are distributed as position and velocity vectors, in SIT 215 and SIT 216 messages. While
these messages are normally sent in a SIT 215 format, the SIT 216 message format is used to send
a new set of elements after each satellite manoeuvre. The distribution procedures for these orbital
elements are explained in section A.7.2 of this Handbook. The message formats are explained in
section B.6.1 of this Handbook.
Since LEOLUTs are required to maintain orbit data internally (except during the period
immediately after a satellite manoeuvre), using the measurements of the satellite downlink carrier
frequency and the data received from designated system reference beacons, the data from the Space
Segment Providers is usually not essential to the successful operation of the LEOLUT. However,
it does provide a reference that is used to verify the orbit data that is used by the LUTs. Each time
it receives a new set of orbital elements, the MCC is required to compare these elements to the

6-23

validated data that it already has, either from the MCC associated with the Space Segment Provider
or from its associated LEOLUT. The criteria for matching the orbital elements are defined
individually for each MCC. The action that is taken as a result of this comparison will depend on
the desires of the Ground Segment Provider, as expressed in the configuration of the MCC:
• If the new data matches the MCC data, then no action is required. The MCC and associated
LEOLUTs can continue to use the data that they already have.
• If the new data does not match the MCC data, then the MCC operator is notified, and
should follow the MCC’s internal procedure to decide whether or not to accept the new
data.
The decision about sending MCC orbit vectors to an associated LEOLUT should take into account
the accuracy of Doppler solutions generated by the LEOLUT for the associated satellite (and
further discussed below) and the fact that the installation of new orbital element data may cause
the loss of the calculated orbital history in some LEOLUTs.
As reflected in the MCC’s internal procedure, the decision to use new orbital data should consider
the quality of the solutions that have been generated by this LEOLUT using beacon messages
relayed through the spacecraft in question (as determined, for example, by the QMS validation
done by the nodal MCC):
• If the solution data generated by this LEOLUT – satellite combination (since the satellite
was last manoeuvred) has been accurate, then the existing elements are reasonably good,
and the new elements may safely be rejected.
• If the solution data generated by this LEOLUT – satellite combination has been of dubious
quality, then the existing elements may not be good, and the new elements may be accepted
and installed.
In either case, the MCC operator is advised to check with the MCC associated with the Space
Segment Provider to confirm that the new elements are valid.
A sample of a SIT 215 message is available in Annex C of the SID. The format of the SIT 216
message is the same as that of a SIT 215 message; the only difference is the value in the SIT
number field (MF \#4).
6.10.2 MEOSAR Orbital Elements
The spacecraft that are used in the MEOSAR Space Segment are all satellites whose primary
mission is a Global Navigation Satellite System (GNSS). In support of that mission, these satellites
transmit their orbital data in the navigation downlink signals. Some MEOLUTs are designed to
retrieve the precise orbital elements for the MEOSAR satellites from this navigation signal to
generate accurate DOA position data.
MEOSAR satellite orbital elements are distributed by the MCC associated with the Space Segment
Provider in the SIT 217 messages, using the Two-Line Element (TLE) format described in section

6-24

C.3 of this Handbook. This orbital data is used by the MCC to validate DOA and encoded position
data generated from MEOSAR satellite data.
6.10.3 GEOSAR Orbital Elements
The GEOSAR satellites are stationary with respect to the surface of the Earth. Each GEOLUT is
configured to receive the data from one satellite, so it is not essential that the GEOLUT have orbital
elements for the detection and processing of the beacon data. There is no provision to distribute
GEOSAR satellite orbital elements through the Cospas-Sarsat data distribution system.
However, the measurement of the frequency of the signals received from a beacon will be slightly
affected by the small relative motion of the satellite. Therefore, to achieve the desired frequency
measurement accuracy, some GEOLUTs do retrieve the satellite orbit data (from the web sites
listed in Table 6-1) and use that data to correct the measured frequency.
6.10.4 LEOSAR SARP Calibration
The Search and Rescue Processor (SARP) instruments on the LEOSAR Sarsat spacecraft, which
are supplied by the French Centre National d’Etudes Spatiales (CNES) as the Space Segment
Provider, measure the time and frequency when each beacon message is received at the satellite.
The data from the SARP instruments on the Sarsat spacecraft is encoded using data from the Ultra-
Stable Oscillator (USO) in the SARP. To decode that data, each LEOLUT requires information
about the SARP:
• the precise frequency of the USO,
• the time of a recent rollover of the time counter in the SARP (at which the time counter
had a value of 0).
This information can be computed from the data collected from the time calibration reference
beacon, which is also operated by CNES.
To ensure that the Ground Segment always has reliable SARP calibration data, this information is
computed by CNES, and is distributed on a weekly basis through the French MCC (FMCC) to all
Ground Segment Operators in SIT 415 (for SARP-2 instruments) and SIT 417 (for SARP-3
instruments) System Data Messages. The formats of these messages are described in more detail
in section B.6.2 of this Handbook.
Many LUTs can compute this SARP calibration data directly from the data that they receive from
the CNES reference beacon. This enables them to operate independently of the data distributed by
the FMCC.
It should be noted that this applies only to the LEOSAR Sarsat spacecraft. The SARP instruments
on the LEOSAR Cospas spacecraft encode the time measurements as Moscow Standard Time, and
the frequency as a real value, so that no interpretation is required to compute the actual time and

6-25

frequency measurements reported by the Cospas SAR instruments. Time calibration is not required
for processing SAR incident data from Cospas spacecraft.
When an MCC receives a SARP Calibration message, it should validate the calibration data and
then forward it to its associated LEOLUTs. Each LEOLUT may then use this data to validate its
own calibration, and to update it as necessary.
If the SARP calibration data that is received does not match the data that is already available in
the MCC, this anomaly is reported to the operator, who should follow the MCC’s internal
procedure to determine which data is valid for future use. Normally, if the LEOLUT has been
producing accurate solutions for beacons relayed through this spacecraft, the calibration data that
has been used is probably valid.
In accordance with the section entitled “Reactivation of the SARP Instrument” in document
C/S A.001, when notification about new SARP TCAL data is received by the MCC (following
deactivation of the SARP instrument), the MCC Operator should follow the MCC’s internal
procedure to:
a) Ensure that the calibration time in the new SARP TCAL data is treated as valid in the
MCC, without regard to previous SARP TCAL data;
b) Validate the USO frequency per normal procedures;
c) Ensure that the new SARP TCAL data (validated as noted above) is used to initialize
the SARP TCAL data in associated LEOLUTs, without regard to previous SARP
TCAL data; and
d) Ensure that all Doppler solutions generated by associated LEOLUT(s) that contain
SARP data for the associated satellite are filtered, until new SARP TCAL data has
been loaded into the associated LEOLUT(s).
Samples of a SIT 415 message and a SIT 417 message are available in Annex C of the SID.
6.10.5 LEOSAR SARR Calibration
The Search and Rescue Repeater (SARR) instruments on the LEOSAR Sarsat spacecraft, which
are supplied by the Canadian Department of National Defence (DND), as the Space Segment
Provider, relay each beacon message received at the satellite to the LEOLUTs on the ground. The
data from the SARR instruments on the Sarsat spacecraft is shifted in frequency by the oscillator
in the SARR. When the SARR data is used in combination with the data from the SARP instrument
to generate Doppler position data, it is essential that the frequency is measured accurately.
To ensure that the frequency reported in the LEOLUT solution data is correct, the frequency
received when known reference beacon signals are relayed through the instrument is measured,
and the exact frequency offset generated in the SARR is measured. The Canadian Technical
Evaluation Centre (CTEC) performs these measurements and distributes the frequency offset
values through the Canadian Mission Control Centre (CMCC) and the MCC network in the

6-26

SIT 510 message. The format of this message are described in more detail in section B.6.3 of this
Handbook. A sample of a SIT 510 message is available in Annex C of the SID. As indicated in the
Table “System Information Messages” in document C/S A.001, few MCCs process the SIT 510
message.
As long as there is a suitable reference beacon within the local coverage area of the LEOLUT,
these computations can also be done in the LEOLUT. In this case, the LEOLUT can continue to
operate independently of the data received from the CMCC. It should also be noted that a LEOLUT
that does not perform the combined SARP-SARR processing does not require this calibration data
for the accuracy of its independent Doppler location solutions. However, without this calibration
data, the accuracy of the beacon frequency that is reported in the incident alert messages may not
be accurate.
When an MCC receives a SARR Calibration message, it should validate the calibration data and
then forward it to its associated LEOLUTs as needed, per national procedures. Each LEOLUT
may then use this data to validate its own calibration, and to update it as necessary.
If the SARR calibration data that is received does not match the data that is already available in
the MCC, this anomaly is reported to the operator, who should follow the MCC’s internal
procedure to determine which data is valid for future use. Normally, if the Doppler position data
is accurate in the combined SARP-SARR solutions that have been produced by this LEOLUT for
beacons relayed through this spacecraft, the calibration data that has been used is valid.
6.10.6 MEOSAR SARR Calibration
The Difference of Arrival (DOA) calculations that are performed in a MEOLUT to compute the
independent location of each beacon that it detects depend on the accuracy of the measurements
of the time and frequency when the beacon signals arrive at each satellite in the MEOSAR
constellation.
To provide sufficiently accurate time and frequency measurements for the computation of DOA
position data in a MEOLUT, each MEOLUT uses one or more of the MEOLUT reference beacons
that are visible to the satellites that it tracks to calibrate the data that it receives and processes.
Because of the wide area of view of a MEOSAR satellite, it is not necessary that each MEOLUT
operator have a separate reference beacon. Instead, a network of MEOSAR reference beacons is
available, operated by various Ground Segment Providers who wish to support the MEOSAR
system. These beacons are identified and specified in document C/S T.022, “Cospas-Sarsat
MEOSAR Reference Beacon Network Design Guidelines”.
Since each MEOLUT can calibrate its own time and frequency measurements, there is no need for
the distribution of MEOSAR calibration data through the MCC network.

6-27

6.10.7 GEOSAR SARR Calibration
A GEOLUT is required to compute the transmit frequency to an accuracy of 2 Hz or better for
each beacon that is detected and reported to its associated MCC. Since there is a possibility that
the frequency will be modified by the Doppler effect as the signal travels to and from the satellite,
and again as the signal travels through the GEOSAR spacecraft and the GEOLUT receive
equipment, it is necessary to calibrate the measured frequency data before it can be processed and
reported in an incident alert message.
Since each GEOSAR satellite can see almost one-third of the Earth’s surface, every GEOLUT
always has at least one reference beacon visible to it. The transmit frequency of each reference
beacons is well known and may be published in documents C/S T.006, “Cospas-Sarsat
Orbitography Network Specification” or C/S T.022, “Cospas-Sarsat MEOSAR Reference Beacon
Network Design Guidelines”. The status of each MEOSAR reference beacon is also available on
the Cospas-Sarsat web site, under the <System> tab. So one or more of these beacons can be used
in the GEOLUT to calibrate its frequency measurements.
Since each GEOLUT can calibrate its own frequency measurements, there is no need for the
distribution of GEOSAR calibration data through the MCC network.
6.11
Satellite Manoeuvres
Each of the spacecraft in the Cospas-Sarsat Space Segment is a satellite that is in orbit around the
Earth. Many of these satellites are in stable orbits; once they are in the orbit, they automatically
continue in the orbit without any further attention from the controllers on the ground. However, in
order to maintain the desired orbit, some of the LEOSAR satellites must be manoeuvred at
intervals.
The satellite manoeuvres are generally small adjustments, made by firing a small rocket to move
the satellite to the desired orbital position or direction. There are two different types of manoeuvre
that may be applied to the LEOSAR satellites:
• An in-plane manoeuvre adjusts the direction or speed of the satellite in the same orbit plane.
The effect of an in-plane manoeuvre on the Doppler location processing increases as time
passes.
• An out-of-plane manoeuvre changes the plane of the satellite orbit. The effect of an out-
of-plane manoeuvre is limited; it does not change significantly with the passage of time.
The procedures to be followed when a LEOSAR satellite manoeuvre is planned are described in
section 3.6.5 (“Scheduled Satellite Manoeuvres”) of the DDP (document C/S A.001). One MCC
(associated with or designated by the Space Segment Provider) is responsible to notify the other

6-28

Ground Segment Providers of the plans for any manoeuvre. This notification will be provided to
all MCCs through a system status (SIT 605) message (see Figure 6.12):
• If the expected effect of the manoeuvre on the Doppler locations that are produced with
data from this satellite is small (less than 2 kilometres impact within 24 hours), no further
action is required at the MCC or at the LEOLUT.
• For a manoeuvre that is expected to change the Doppler location by more than 2 kilometres
within 24 hours after the manoeuvre, the MCC shall be configured to:
o  treat orbit ephemeris data received in a SIT 216 message within 24 hours after the
end of the manoeuvre as valid, if they are within the maximum tolerance specified
for the satellite in the associated System status message; and
o use the validated SIT 216 orbit ephemeris data to immediately initialize orbit
vectors at the MCC and its associated LUTs;
• For a manoeuvre that is expected to change the Doppler location by more than 10
kilometres within 24 hours after the manoeuvre, then the associated MCC shall be
configured to provide warning information on alert messages sent to SPOCs and RCCs
about the potential error in Doppler location data for that satellite. This warning should
continue until 24 hours after the end of the scheduled manoeuvre.
The MCC should have an internal procedure to ensure that the MCC is properly configured to
handle satellite manoeuvres, as described above (and in the section titled “Scheduled Satellite
Manoeuvres” in document C/S A.001). The MCC operator should be capable of executing this
procedure, as required nationally. At a minimum, the MCC operator is required to recognize
SIT 605 messages regarding satellite manoeuvres and to ensure that appropriate MCC support
personnel are notified.
If the MCC has not received any new orbital elements for this satellite within 24 hours of the
manoeuvre, the MCC operator should make inquiries of the responsible MCC to get the new orbit
data for their LEOLUTs.
In addition, MEOSAR satellites may be manoeuvred. Based on notification provided by the
responsible MCC, MCCs may need to adjust the MCC orbital data validation thresholds for the
satellite temporarily and take action to remove the satellite from the associated MEOLUT(s)
schedule temporarily.
Per MCC internal procedures, the MCC operator may not do the above tasks directly, but may
instead report the manoeuvre to the MCC support personnel to ensure that the appropriate action
is taken.

6-29

/12345 00000/3660/05 123 1412
/605/5030
/TO: ALL MCCS
FROM: <MCC RESPONSIBLE FOR THE SATELLITE MANOEUVRE >
SUBJECT: MANOEUVRE OF SATELLITE <XNN>
STATUS OF MANOEUVRE: <SCHEDULED, EXECUTED OR CANCELLED>
TYPE OF MANOEUVRE: <IN PLANE, OUT OF PLANE OR BOTH>
SAR INSTRUMENTS ACTIVE DURING MANOEUVRE: <YES OR NO>
MANOEUVRE START TIME: <DD MON YEAR HHMM> UTC
MANOEUVRE END TIME: <DD MON YEAR HHMM> UTC
[REPEAT INFORMATION ABOUT MANOEUVRE START AND END TIME AS
NEEDED]
TIME NEW ORBIT VECTORS ARE EXPECTED: <DD MON YEAR HHMM> UTC
MAXIMUM EXPECTED CHANGE IN SATELLITE POSITION DUE TO THE SATELLITE
MANOEUVRE: <XX> KM AFTER <YY> HOURS
MAXIMUM EXPECTED ERROR IN DOPPLER LOCATION: <XX> KM AFTER <YY>
HOURS
THIS DOPPLER LOCATION ERROR INCLUDES A NOMINAL SYSTEM ERROR OF
5 KM.
COMMENTS - MCCS SHOULD <EXECUTE OR REFER TO> PROCEDURES ON
SATELLITE MANOEUVRES CONTAINED IN SECTION 3.6.5 OF C/S A.001.
QQQQ
/LASSIT
/ENDMSG
Figure 6.12: Sample Message to Announce a LEOSAR Satellite Manoeuvre
This is a template for a system status message to be sent by the responsible MCC to announce a
planned LEOSAR satellite manoeuvre.

6-30

Figure 6.12 is a copy of Figure 5.2 (“Standard Message for Reporting Satellite Manoeuvres”) from
the DDP (document C/S A.001); it contains a template for the system status message (SIT 605)
that should be sent by the responsible MCC to announce a LEOSAR satellite manoeuvre.
6.12
Satellite Outages
The individual spacecraft that comprise the Cospas-Sarsat Space Segment are all designed for
other primary missions, and are used as satellites of opportunity to carry the Search and Rescue
instruments, the Search and Rescue Processor (SARP) and the Search and Rescue Repeater
(SARR), that are described in section 3.4 of this Handbook. Because the SAR mission is not the
primary purpose of the spacecraft, if any component fails, the spacecraft may not be repaired or
replaced; instead, it may continue to operate in a degraded mode.
Spacecraft anomalies and failures may be detected and reported through various channels, as
explained in section 5.3.4 of this Handbook. As explained in that section, any spacecraft anomaly
is reported to all MCCs of the Cospas-Sarsat Ground Segment in a system status message.
If a SIT 605 is received saying that a satellite is completely out of service, the MCC operator
should follow local procedures to remove that satellite from its LUT tracking schedules, and the
MCC should filter any data from that satellite in the future.
If the SIT 605 message indicates that the spacecraft is continuing to operate in a degraded mode,
the situation is more complex.
If the problem cannot be resolved, then it may be necessary to modify the Ground Segment to
work around the problem. This may be a temporary solution, recommended in a system status
(SIT 605) message, until the problem can be resolved in the Space Segment. Alternately, if a
problem cannot be solved in the Space Segment, the revised ground segment processing may
become a permanent solution. While this is temporarily defined in the system status message, it
will eventually be reviewed by the Cospas-Sarsat Joint Committee and approved by the Council
as an amendment to the appropriate System document.
When an MCC operator receives a system status message that proposes a modification to the
Ground Segment processing of data from a degraded satellite, they must take the appropriate action
to implement the requested change. Several actions are possible at this point:
• If the modification can be implemented by a change in operating procedures at the LUT or
MCC, the appropriate procedure documents at the MCC (and/or LUTs) must be updated
to show the new procedures. The new procedures should be implemented as soon as
possible, or as specified by the Space Segment Provider.
• If the modification can be implemented by a change to the national ground segment
configuration, the MCC or LUT should be updated and the new configuration recorded in
the appropriate national documents. (This is necessary to ensure that the modified

6-31

configuration is not removed at a later time by someone who was not aware of the revised
requirement.)
• If the modification requires a change to the equipment or software at the LUT or MCC, the
change should be scheduled. If any contractual arrangements are required to implement the
change, the appropriate person(s) should be notified, so that the specifications and
contractual documents can be prepared, as necessary.
• If the modification is expected to be a long-term change that will be raised and discussed
at the Cospas-Sarsat Joint Committee (JC), then the national representative to Cospas-
Sarsat and the Head of Delegation to the JC meeting (if that person has been identified)
should be notified. They should also be informed of any immediate (or foreseen)
consequences of the proposed modification.
Depending on the nature of the proposed modification, more than one of these actions may be
necessary. In each case, the action may be taken by the MCC operator, or the MCC operator may
inform the MCC System Manager, who can then perform the action or ensure that the action is
followed through.
6.13
Coverage Analysis
An RCC may ask for information about the satellite coverage available to assist with the planning
of SAR operations. While not an MCC operator requirement, an MCC operator may provide
information on satellite coverage availability, based on tools available at the specific MCC.
Note that SIT 185 messages provide information about LEOSAR satellite visibility (in Message
Field \#29, titled “NEXT TIME OF VISIBILITY”), based on optional LEOLUT pass schedule
information available at the associated MCC. Also, per document C/S A.001, new DOA position,
if available, is distributed at least every 5 minutes prior to position confirmation and at least every
15 minutes after position confirmation.
6.13.1 LEOSAR Coverage
The LEOSAR system provides two types of coverage:
• Each LEOLUT provides local coverage, based on the beacon messages relayed through the
SARR instruments on the LEOSAR satellites. For any given satellite pass, the coverage is
limited to a swath about three thousand kilometres across, centred on the satellite ground
path. As each incident alert is reported, the LUT generates an estimate of when the LUT
next expects to see a satellite that will also have visibility of the location. This “Next Time
of Visibility” is reported in the incident alert messages in Message Field number 29. (See
also section C.1.8 of this Handbook.)
• Every LEOLUT also provides global coverage, based on the data collected by the SARP
instruments on the LEOSAR satellites. This data will be from all the beacons that the
satellite has passed since it was last tracked by this LEOLUT. Since the coverage at any

6-32

instant depends on the past history of the satellite that will next be tracked by the LUT, it
is not easy to determine when a LEOLUT is likely to generate an alert for a beacon at any
given location.
Since the MCC Service Area is normally in the area around the MCC and its associated LUTs, the
RCCs and SPOCs in that Service Area are most likely to make inquiries about the local coverage
of the LUTs.
An MCC operator can review the satellite pass schedule for each of the associated LEOLUTs and
estimate when the LUTs are likely to provide coverage of a specific location that may be of interest
to the RCC. It may also be possible for the MCC operator to change the schedule to have the LUT
track a different satellite to get better coverage of the point of interest.
6.13.2 MEOSAR Coverage
The MEOSAR system provides a vast coverage area around each MEOLUT. Nominally, one
MEOLUT should be able to provide DOA solution data for any beacon within two thousand
kilometres of the LUT. At Full Operational Capability, the MEOSAR system has enough
operational MEOLUTs and enough operational MEOSAR satellites to provide complete coverage
of the surface of the Earth. So, any beacon, anywhere on the Earth, should be accurately located
within about ten minutes after it has been activated.
6.13.3 GEOSAR Coverage
The coverage that is available to a GEOLUT is determined by two things:
• the area which the GEOSAR satellite can see and from which it can receive beacon
messages (its visibility footprint),
• local blockages in the area around a beacon.
Subject to these two considerations, the GEOLUT should be able to detect and receive messages
from any beacon at any time.
The major coverage limitation for the GEOSAR system is around the poles: none of the GEOSAR
satellites can see any beacon that is at a latitude that is higher than about 70°.
6.14
Beacon Testing
The Cospas-Sarsat beacons may be involved in a variety of types of tests:
• a beacon self-test,
• a test beacon or beacon simulator,
• a planned beacon test,

6-33

• a System-wide test.
Each type of test requires a different notification and a different response from the MCC operator,
as explained in the remaining parts of this section.
6.14.1 Beacon Self-Test Messages
Every Cospas-Sarsat distress beacon is equipped with a self-test capability. This is activated by
the operator of the beacon (using a specific control feature on the beacon); it will transmit one
burst (one beacon message). This self-test transmission is identified as such in the encoded
message:
• For an FGB, the message preamble is inverted from the normal preamble, as defined in the
FGB specification (document C/S T.001).
• For an SGB, the message is transmitted with a distinct spreading code sequence, as defined
in the SGB specification (document C/S T.018), and it includes a bit in the message that
identifies this as a test transmission.
In both cases, the message is immediately recognized as a test transmission. These self-test
transmissions may be suppressed at the LUT, or they may be forwarded to the associated MCC.
(Some MCCs analyze these self-test transmissions to help them to evaluate the accuracy of their
estimates of beacon population and registration rates.) Per MCC requirements, self-test
transmissions are not distributed as distress transmissions by the MCC.
However, when a beacon sends several self-test messages over a relatively short period of time,
and the data is received by a SARSAT satellite with a SARP-3 instrument (i.e., S11, S12 or S13),
then an associated distress alert may be sent to the RCC. Awareness of this anomaly, resulting
from a beacon transmission anomaly combined with a satellite processing anomaly, may allow the
MCC operator (or other MCC personnel) to help the RCC or SPOC recognize the anomaly and
respond, to ensure that the RCC informs the owner that the beacon is not operating correctly and
that the beacon (whose battery may have been prematurely depleted) should be examined by a
qualified service centre to ensure that it will operate correctly in the future.
6.14.2 Test Beacons and Beacon Simulators
A test beacon has an encoded message that identifies it as such. The details of the beacon message
protocols that identify test beacons are described in the appropriate 406 MHz beacon specification
(document C/S T.001, C/S T.015, or C/S T.018). A test beacon will always transmit the test
protocol message, and an MCC can recognize any alert message that it receives from a test beacon.
A beacon simulator is a specialized instrument that transmits messages that meet the requirements
of one or more of the beacon specifications. The message may indicate that it is from any 406 MHz
beacon, including a distress beacon of any type or a test beacon. When one of these messages is
received at a LUT, it is processed as if it were from a real 406 MHz beacon, and forwarded to the

6-34

associated MCC, as appropriate. That MCC distributes the alert according to the requirements for
the type of beacon from which it appears to have been sent.
6.14.3 Notification of a Planned Beacon Test
A beacon test (as distinct from a beacon self-test transmission) is the planned activation of a
406 MHz beacon for the purpose of testing the beacon or some part of the Cospas-Sarsat System.
Such a beacon test is normally planned in advance, and must be authorized by the appropriate
MCCs:
• the MCC in whose Service Area the beacon will be activated,
• the MCC whose Service Area includes the nation whose country code is encoded in the
beacon message.
Section 4.3 (“Procedures for the Co-Ordination of Beacon Tests”) of document C/S A.001
specifies the procedure to be followed by an MCC in approving and coordinating a beacon test.
Because of the global scope of the Cospas-Sarsat System, an MCC that authorizes a beacon test is
expected to notify affected (designated) other MCCs of the planned test.
A template for a Beacon Test Co-ordination Message is provided in Figure 4.16 in section 4.3
(“Procedures for the Co-Ordination of Beacon Tests”) of document C/S A.001. Figure 6.13
contains a sample of a message to notify affected (designated) MCCs of a planned beacon test.

6-35

/20462 00000/5030/20 099 1721
/915/5670
/FM ITMCC
TO AFFECTED (DESIGNATED) MCCS
SUBJ : 406 MHZ ELT BEACON TEST
A. TEST OBJECTIVE: FUNCTIONAL ELT BEACON
B. TEST DESCRIPTION: NIL
C. LOCATION OF TEST: VERGIATE-ITALY
LAT 45 42' 47''N LONG 008 41' 57''E
D. DATE/TIME AND DURATION OF TEST:
10 APRIL 2020 FROM 1300 UTC TO 1500 UTC
E. BEACON 15 HEX ID CODE: 1EE87E23D6FFBFF
F. SPECIAL DATA COLLECTION AND PROCESSING REQUIREMENTS:
PLEASE FILTER ALERTS FROM THIS BEACON.
G. POINT OF CONTACT
NAME: OPERATOR ITMCC
LOCATION: ITMCC OPERATIONAL ROOM
TELEPHONE NO: +39 080 5344033-5341571
AFTN NO: LIJCYFYX
FACSIMILE NO: +39 080 5342145
THANK YOU FOR YOUR COOPERATION
BEST REGARDS
ITMCC.
QQQQ
/LASSIT
/ENDMSG
Figure 6.13: Sample Message to Announce a Planned Beacon Test Activation
This is a sample of a system status message to notify affected (designated) MCCs of the plans for the
activation of a 406 MHz beacon in support of a system test.
Requirements for the coordination of beacon tests, including limits on the number of beacons that
can be tested and required notification, are provided in document C/S A.001 sections entitled
“Coordination of Beacon Tests” and “Procedures for the Co-Ordination of Beacon Tests”. At a
minimum, the MCC operator should be able to identify beacon test requests received from MCCs
or other agencies and should follow the MCC internal procedure to ensure that the beacon test
request is handled properly.

6-36

6.14.4 Processing Data from a Beacon Test
The notification of the test should include an indication of what action may be expected of other
MCCs during the test. There are a number of possibilities; the other MCCs may be asked to:
• Ignore the beacon transmissions and suppress distribution of all alerts that may be
generated as a result of this test. (See line F in the sample message in Figure 6.13.)
• Forward all data received from these test transmissions to the coordinating MCC.
• Perform specific processing of the data from the test transmissions and send the results to
the coordinating MCC.
In most cases, most (or all) of the other affected MCCs will be asked to either suppress the data or
forward it to the coordinating MCC; in these cases, the request should be included in the system
status message that is sent to announce the test.
If specific processing is required, then it should be well-documented. (For example, the
transmission and processing of test messages during the commissioning of a LUT system should
be described in the LUT Commissioning Test Plan.) The document that describes the required
processing should be made available to all MCCs involved, and especially to those MCCs that
may be asked to perform any specialized processing. If the processing is required of only one (or
a few) MCCs, then the request can be sent separately in a narrative message to the affected MCCs.
In response to a beacon test request, the MCC may be required to:
• Change the configuration of the MCC to support a request to distribute or suppress alert
data.
• Provide supporting data that is not automatically distributed for operational beacon alerts.
As noted above, the MCC operator should follow the MCC internal procedure to ensure that the
beacon test request is handled properly.
6.14.5 System-Wide Tests
There are occasionally system-wide tests of specific features or capabilities of the Cospas-Sarsat
System, such as the MEOSAR Development and Evaluation (D&E) Program.
In the event that any such system-wide exercise is planned, it will be well-documented. A D&E
Plan or a Test Plan document will be prepared and reviewed by the Cospas Sarsat Joint Committee,
and all MCCs will be notified well in advance of the planned exercise. An exercise director or a
test coordinator (and possibly a coordinating committee) will be named, and they will provide
suitable notifications to all participants, both in advance of the test and during the progress of the
tests. On completion, the Test Coordinator or Test Committee will generate a Test Report, to be
reviewed by the Joint Committee and recommended to the Council for approval as a formal
Cospas-Sarsat document.

6-37

The extent of the participation of individual MCCs in any such system-wide test will be determined
by the nature of the test and by the administration of the Ground Segment Provider that operates
the MCC. In general, the MCC operator is expected to follow established procedures during the
test, and, as appropriate, to follow any new procedures that are being evaluated during this system-
wide activity. Depending on the scale of the planned test activities, the MCC System Manager may
adjust the MCC staffing schedule to ensure that the personnel on duty at any time will be prepared
to handle the requirements of the test activities.
Appropriate MCC personnel may be requested to participate in the analysis of the data from the
tests and to assist in the preparation of the final report of the tests.
- END OF SECTION 6 -

Annexes to the MCC HANDBOOK
C/S G.010
Issue 1 – Revision 2

![Image 1 from page 136](/images/cospas-sarsat/G-series/G010/G010_page_136_img_1.png)

Annexes to the MCC HANDBOOK
HISTORY
Issue
Revision
Date
Comments


Approved by CSC-64


Approved by CSC-66


[Approved by CSC-69]

A-1

ANNEX A: DATA DISTRIBUTION
The rules and procedures for the distribution of incident alert data and system data through the
Cospas-Sarsat System are set out in document C/S A.001, “Cospas-Sarsat Data Distribution Plan”
(the DDP). This section provides a summary and a brief explanation of these rules and procedures.
Document C/S A.002, “Cospas-Sarsat Standard Interface Description” (the SID), defines the
formats and contents of the messages that are exchanged among the MCCs in the System. The
message formats that are used for the exchange of incident alert data are described in Annex B of
this Handbook.
A.1
Nodal Data Distribution Network
As described in section 4.3 of this Handbook, the Cospas-Sarsat data distribution network is
divided into a set of Data Distribution Regions (DDRs), each of which is served by a nodal MCC.
This organization isolates most of the individual MCCs from the complexities of the world-wide
data distribution requirements. Except for the nodal MCCs, each MCC is only required to maintain
information about its own local Service Area.
An incident is of direct interest to an MCC Service Area if:
• the incident alert includes a location that is in the geographical area of the SRR of an RCC
that is supported by the MCC (according to the Cospas-Sarsat GEOSORT); or
• the incident alert is from a beacon that contains the country code of one of the nations that
is included in the MCC Service Area.
For each such local alert, the MCC must be able to determine which national RCC or foreign SAR
Point of Contact (SPOC) is responsible for the alert and must transmit the alert to that RCC or
SPOC.
For any incident alert that is not of direct interest to the MCC Service Area, the MCC simply sends
the alert message to its nodal MCC for further processing and distribution. The nodal MCCs are
then responsible for information about the requirements for distribution of incident alert messages
to the rest of the world:
• If the location is within its own DDR, the nodal MCC must determine the Service Area in
which it lies and send the alert to the MCC responsible for that region.
• If the location is outside its own DDR, the nodal MCC must determine the DDR in which
it lies and send the alert to the nodal MCC responsible for that DDR. That nodal MCC will
then forward the alert to the responsible MCC within its own DDR.

A-2

In each case, the non-nodal MCCs only require information about their own Service Area, while
each nodal MCC must be aware of the structure of the data distribution network both inside and
outside of its own DDR.
However, as noted in section 4.3.2, the MCCs of the Central DDR have agreed that all MCCs in
that DDR will exchange alerts directly, without going through the nodal FMCC. For this reason,
every MCC in the CDDR must have the complete GEOSORT for the CDDR.
A.1.1
Special Rules
The general rules that are set out in the Cospas-Sarsat Data Distribution Plan are all subject to
variation by mutual agreement among MCCs, or between an MCC and one or more of its SPOCs.
The major example of such an agreement is in the Central Data Distribution Region (CDDR),
where each MCC has accepted the responsibility to send an incident alert for another CDDR MCC
directly to the destination MCC without going through the nodal French MCC.
A.1.2
Cospas-Sarsat GEOSORT
The Cospas-Sarsat GEOSORT is a database that contains the list of boundary points of the Service
Area of every commissioned MCC. It is maintained by the Cospas-Sarsat Secretariat, and it is
reviewed and updated as necessary by the Cospas-Sarsat Joint Committee; it is made available on
request to any of the MCCs in the Cospas-Sarsat Ground Segment.
Each MCC supplements the Cospas-Sarsat GEOSORT with its own database, which contains the
list of boundary points of the SRRs of every RCC or SPOC that is served by that MCC.
Each MCC uses this data to decide which region contains any point (usually a beacon location) of
interest to the MCC and to determine the appropriate destination for that incident alert message.
The nodal MCCs use the complete GEOSORT to determine the MCC Service Area that contains
a beacon position. Once the MCC has determined the MCC Service Area to which a beacon
location belongs, it can then proceed to send the incident alert message for that beacon to the
appropriate MCC, to be forwarded to the SAR service that will deal with the distress incident.
A.1.2.1
Data Distribution Regions
As noted in section 4.3.2, above, a Data Distribution Region (DDR) is the region that is managed
by a nodal MCC; each DDR consists of the collected Service Areas of all the MCCs that are
supported by that nodal MCC. When a nodal MCC is considered for commissioning into the
Cospas-Sarsat Ground Segment, the set of MCC Service Areas that will be served by that nodal
MCC are proposed and reviewed by the Cospas-Sarsat Joint Committee; the final set of agreed
MCC Service Areas is then approved by the Cospas-Sarsat Council.
The existing Cospas-Sarsat data distribution system is comprised of six different DDRs, as listed
in Table 4-2 and illustrated in Figure 4.4.

A-3

A.1.3
MCC Service Areas
As explained in section 4.3.1, an MCC Service Area is the region that is serviced by the MCC.
When a new MCC is commissioned into the Cospas-Sarsat Ground Segment, the Service Area that
will be supported by that MCC is agreed and the set of boundary points for the region are included
in the Cospas-Sarsat GEOSORT database.
A.1.4
Message Formatting
The messages that are used to transmit information from one MCC to another, or to a SPOC, are
formatted according to the requirements of the document C/S A.002 (Standard Interface
Specification), as described in Annex B of this Handbook.
As explained in that Annex, each message is built from a series of data message fields (MFs), each
of which contains a specific item of information about the solution. The tables in this Annex A
identify the data that is contained in the various messages; they include (in the “References”
column) references to the sections or the tables in Annex B that provide more comprehensive
explanations of the message fields that are used to hold that data.
Every message includes the message control fields described in section A.10.1 of this Handbook.
Each individual message also includes the data message fields, as identified in the tables in the
following sections of this Annex A and in Annex B that describe the information appropriate to
the specific message that is being prepared.
A.1.5
Alert Message Validation
As each incident alert message is received by an MCC, the contents of that message are checked
and validated. Several types of message validation are performed:
• Each character in the message is checked to ensure that its contents are consistent with the
specifications in the SID (document C/S A.002).
If the message fails this initial validation, then it cannot be processed by the MCC. The operator
is notified and should contact the originator of the message:
• If a valid incident alert was sent, then the message should be re-transmitted and processed
when it is correctly received.
• If the message was not valid as sent, then the originator of the message should make the
necessary corrections and send the valid message for processing.
A message that passes the initial validation is then checked to verify the data in the beacon message
that is contained in the alert:
• The Bose–Chaudhuri–Hocquenghem (BCH) error correcting code (ECC) is checked to
ensure that the beacon message contained in the alert has not been corrupted in
transmission. See section A.6.7 in Annex A of this Handbook for a more complete
explanation of the bit error processing.

A-4

• Selected supplementary data fields in the beacon message are checked (as described in
section 4.2 of C/S A.001) to ensure that their contents are valid. These fields, and the valid
contents, are identified in the DDP.
If the beacon message data passes all the validation checks, then the message is accepted as valid
and is processed. If the beacon message fails any validation check, then the alert will still be
processed, but none of the data that is contained in the beacon message will be used in the
processing.
Essentially, an alert containing a beacon message that fails validation will be processed according
to the independent location data that may be contained in the alert. However, any other data from
the beacon message, such as the country code or the encoded location data, will not be accepted
as valid, and will not be used to determine the subsequent processing of that alert.
A.2
Alert Data Distribution
The rules for the distribution of incident alert data are set out in the DDP (document C/S A.001)
and are detailed in a series of tables (called “Processing Matrices”) in section 4 (“Operational
Procedures for Cospas-Sarsat MCCs”) of that document. There is a different table for each set of
conditions under which the message must be distributed. Section A.3 describes the structure and
contents of these processing matrices.
A.3
DDP Processing Matrices
The processing matrices are a series of tables in the DDP that define the processing that an MCC
must do in the various circumstances that may arise. These matrices each contain a series of
subscripted variables that define the data:
• The Input (In) identifies the type of input data that is to be processed by the MCC. The
Input word is specific to each individual input and is independent of the origin of the data
(e.g. another MCC or the LUTs associated with the receiving MCC).
• The current Status word (Swp) indicates the status of the processing of the beacon before
the input data is processed. The Status word summarises all previous inputs and actions in
respect of a particular beacon ID.
• The action word (Awq) indicates the action that the MCC should take as a result of the
processing of In in the situation indicated by Swp. The Actions to be carried out as a result
of the process depend on the Input / Status combination, but also on the results of
comparisons (matching tests) between ‘old’ and ‘new’ position data received by the MCC,
as shown in the matrix that applies to this input message.
• The new status word (Swr) indicates the new status the MCC should set as a result of the
processing of In in the situation indicated by Swp.
This processing is illustrated in Figure 4-10 (“Alert Data Processing Concept”) of the DDP, which
is reproduced in this Handbook as Figure A.1.

A-5

The Action word that is selected as a result of the processing of an input message defines:
• The message format to be sent, and
• (Before position confirmation) the new status to be associated with that beacon ID after
completion of the selected Action.
Figure A.1: Alert Data Processing Concept
This illustration summarizes the functional relationships among the position information content of
the input message, the status word, and the action generated by the MCC processing.
Each of the subscripts denotes the nature of the data to which it relates, as listed in Error! R
eference source not found.1. The subscript for the input will depend on the nature of the input
data that is being processed. In the table, an independent position may be either a LEOSAR
Doppler position or a MEOSAR DOA position (or some combination of Doppler and DOA
positions).
Table A-1: Subscripts used in Processing Matrices
This table defines the meaning of the subscripts that are used in the processing matrices in the DDP
(document C/S A.001).
Subscript
Description

No message received or sent

Unlocated alert

Independent positions only

Encoded position only

Independent and Encoded positions, all unmatched

Independent position only, position confirmed

Independent position (confirmed) and Encoded position unmatched

Resolved positions (Independent & Encoded matched)

![Image 1 from page 142](/images/cospas-sarsat/G-series/G010/G010_page_142_img_1.png)

A-6

As indicated in Figure A.1, the subscript for the new status word, after the processing of this input
message is complete, will have a subscript (r) that is the greater of:
• the subscript (p) of the original status word,
• the subscript (q) of the action word that results from the processing of this input.
The new status word subscript will then be retained to be used to direct the processing of the next
alert received for this beacon.
The processing matrix is then a table that shows the Input word values across the top (from 1 to 7;
a value of 0, meaning no input, is obviously not appropriate) to identify the columns, with one row
for each Status word value (although the entries for Sw5, Sw6, and Sw7 are all treated in the same
row).
Each entry in the table then defines the results to be generated for the relevant combination of input
(In) and current status (Swp). Each entry consists of a block of values that define the results of the
processing of the indicated combination of input and status, as shown in Table , which is an extract
from Table 4-11 (“Processing Matrix, Message Formats and Distribution of New 406 MHz
MEOSAR Alerts”) of the DDP (document C/S A.001).
Table A-2 - Extract from MEOSAR Processing Matrix
This table is an extract from the processing matrix for a new MEOSAR alert; Table 4-11 (Processing
Matrix, Message Formats and Distribution of New 406 MHz MEOSAR Alerts) in the DDP (document
C/S A.001).
I4
(DOA / E unmatched)
Aw SIT Dest
Sw2
Aw7  n47  RIP
Aw6  n47  RIP
Aw4  n46 OEP
This entry shows the processing of a new MEOSAR DOA solution with an encoded position that
does not match the DOA position in the message (I4). The current status when this alert is received
is Sw2, meaning that the MCC has previously received one or more alerts that only contained DOA
(or Doppler) solutions. The results of the MCC processing are indicated in the three lines of the
entry:
Line 1. If the position of the incident is confirmed by the MCC processing, the action is Aw7 (send
an alert message). The MCC should send the alert message in SIT n47 format (SIT 147 or SIT 347,
depending on whether the beacon that sent this alert is an FGB or an SGB; see below). The final
code is RIP, meaning that the MCC should send the alert to the destinations defined by:

A-7

•  (R) the SRR in which the confirmed position is located,
•  (I) SRR in which the incorrect previous position is located,
•  (P) all previous recipients of alerts for this incident.
Line 2. If the position of the incident is confirmed by the MCC processing but the confirmed
position does not match the new encoded position, the action is Aw6 (send an alert message). The
MCC should send the alert message in SIT n47 format (SIT 147 or SIT 347, depending on whether
the beacon that sent this alert is an FGB or an SGB; see below). The final code is RIP, meaning
that the MCC should send the alert to the destinations defined by:
•  (R) the SRR in which the confirmed position is located,
•  (I) SRR in which the incorrect previous position is located,
•  (P) all previous recipients of alerts for this incident.
Line 3. If the position of the incident is not confirmed by the MCC processing and the new DOA
position does not match the new encoded positions, the new action is Aw4 (send an alert message).
The MCC should send the alert message in SIT n46 format (SIT 146 or SIT 346, depending on
whether the beacon that sent this alert is an FGB or an SGB; see below). The final code is OEP,
meaning that the MCC should send the alert to the destinations defined by:
•  (O) the SRR in which the new DOA position is located,
•  (E) the SRR in which the new encoded position is located,
•  (P) all previous recipients of alerts for this incident.
In the “SIT” column, the SIT message format number is listed as “n--”, where n may be:
• For a first-generation beacon, n=1,
• For a second-generation beacon, n=3.
So, in the second row of the example, the MCC would send a SIT 147 message for an FGB and a
SIT 347 message for an SGB.
In the “Dest” (destination) column, the destination code may be any of the letters listed in
Table .
Table A-3: Processing Matrix Destination Codes
This table contains some of the notes from the processing matrix for a new LEOSAR alert; Table 4-10
(Processing Matrix, Message Formats and Distribution of New 406 MHz LEOSAR Alerts) in the
DDP (document C/S A.001).

A-8

Code
Meaning
A
Destinations defined by the A-position of a LEOSAR Doppler solution
B
Destinations defined by the B-position of a LEOSAR Doppler solution
E
Destinations defined by the encoded position in the beacon message
O
Destinations defined by the position of a MEOSAR DOA solution
R
Destinations defined by the confirmed position of the incident
I
Destinations defined by all of the incorrect positions that have been processed previously by
this MCC
C
Destinations defined by the country code that is encoded in the beacon message
RD
Destinations defined by the post-confirmation positions
(that is, all positions found after the initial confirmation of this incident)
P
All previous recipients of alerts about this beacon incident
A.4
Alert Types
A.4.1
Unlocated Alerts
If the alert data does not include any estimate of the location of the beacon, then the incident alert
message will have to be distributed to the country that is identified in the beacon message. (Note,
however, that the country code will only be used if the beacon message is valid; otherwise, the
content of the message, and specifically the country code, is not reliable, and no incident alert
message will be sent for this incident.)
If the country identified in the beacon message is included in the Service Area of this MCC, then
the incident alert message will be transmitted to the associated RCC or SPOC. Otherwise, the
incident alert data will be sent to the nodal MCC that is associated with this MCC, and the nodal
MCC will determine the appropriate onward distribution.
Once the destination has been established, the message format will be decided (as described in the
SID, C/S A.002), and the message text will be generated. The incident alert message will then be
transmitted, as specified in document C/S A.001 (Data Distribution Plan) and described in the
appropriate section of this Annex.
A.4.2
Alerts with Beacon Position Estimates
An incident alert message will usually contain an estimate of the beacon location, which may be
any one or more of:
• An encoded location determined by the beacon and included in a valid beacon message,
• An independent location determined by the Doppler processing in a LEOLUT,
• An independent location determined by the Difference of Arrival (DOA) processing in a
MEOLUT,

A-9

• A confirmed location estimate, based on two or more location estimates of one or more of
the location types listed above.
Whenever a beacon position estimate is available, the MCC evaluates the location against the
Cospas-Sarsat GEOSORT to determine the appropriate destination for that incident alert. It also
considers any information that has previously been received about the same beacon, and,
depending on the evaluation of the processing matrix, determines whether or not a new alert
message should be sent out.
Note that each destination MCC may request the continued distribution or the suppression of alerts
for any specified beacon, and thereby over-ride the automatic routing (or suppression) of future
alert messages from that beacon.
A.4.2.1
Position Data
The position data for every location that is included in every incident alert message (whether it is
a LEOSAR Doppler position, a MEOSAR DOA position, or an encoded position) consists of:
•
Latitude
The latitude is stored internally in the system, and displayed in MF
\#25, as a real number of degrees North or South of the equator. A
positive number indicates North, and a negative number indicates
South.
•
Longitude
The longitude is stored internally in the system, and displayed in MF
\#26, as a real number of degrees East or West of the prime meridian.
A positive number indicates East, and a negative number indicates
West.
The position data that is included in a MEOSAR DOA incident alert message also includes:
•
Altitude
The altitude is stored internally in the system, and displayed in MF
\#82, as a real number of kilometres above the surface of the reference
ellipsoid (the nominal sea level). The value displayed in MF \#82 is
always positive; a value below sea level will show as zero.
The position data is always computed and displayed in the World Geodetic System (WGS84)
reference system. This reference coordinate system is the standard used by the Cospas-Sarsat
System; it is also used by the Global Positioning System (GPS) and is within a few centimetres of
the reference systems used by the other Global Navigation Satellite Systems (GNSS).
A.4.3
Confirmed Beacon Alerts
Before an alert has been confirmed, the location data is sent to the RCC. Although this data may
not have enough information for the RCC to pursue the rescue, the RCC may have information
from other sources that will help to resolve the solution ambiguity, as described in section C.1.2.1
of this Handbook. Alternately, the RCC may have to wait until the MCC can resolve the ambiguity
(as described above). Once the solution ambiguity is resolved, the new alert can be distributed as
a confirmed alert, with sufficient information for the RCC to address the alert.

A-10

If a beacon is detected with a location estimate (either a encoded location in the beacon message
or an independent location estimate from the LEOSAR Doppler processing or the MEOSAR DOA
processing), then the incident alert message is distributed; however, the message format is
specifically labelled to identify it as an unconfirmed alert.
If a beacon is detected through at least two different independent channels, then the messages will
be compared to determine if the beacon activation and detection can be confirmed.
Two data channels are considered to be independent if they contain information that can not have
been duplicated, as explained in section 4.3.4.4 of this Handbook.
Once the alert has been confirmed, a separate message will be distributed to identify that this is a
confirmed alert report.
A.4.3.1
Matching and Merging of Beacons
As each incident alert message is received at an MCC, the alert data is compared to the alert data
that is already held in the MCC (based on previously received alert messages). The first step in
matching the new alert to a previous alert is to compare the beacon identifiers:
• If the beacon message is valid, then the corrected beacon identifiers (without the BCH
code) are matched.
• If the beacon message is not valid, then the entire beacon messages (including all of the
BCH code bits) are matched.
In each case, if a match is found, then the new alert data is compared to the previous data, and the
new alert is processed accordingly.
A.4.3.2
Beacon Confirmation
If the beacon identifications from two independent detections match, as described above, then the
beacon activation may be considered to have been confirmed. That is, the MCC will accept that
the beacon has been activated, and that it should continue to process reports from that beacon
accordingly.
A.4.3.3
Position Confirmation
If the solutions that contribute to a confirmed alert include a location estimate, then the position of
the confirmed solution can also be confirmed. A position estimate is confirmed if a second location
estimate, from an independent source, as described in section 4.3.4.4 of this Handbook, matches
the initial estimate to within the match criteria listed in section 4.2.2 (“Position Matching”) of the
DDP.
A.4.3.4
Distribution of Confirmed Solutions
The specifications for the processing of alert confirmation and ambiguity resolution are contained
in document C/S A.001, in the remaining columns of the processing matrix in Table 4-10

A-11

(“Processing Matrix, Message Formats and Distribution of New 406 MHz LEOSAR/GEOSAR
Alerts”) and Table 4-11 (“Processing Matrix, Message Formats and Distribution of New 406 MHz
MEOSAR Alerts”), and in the accompanying text in sections 4.2.5.3.1 (“Processing Before
Position Confirmation”) and 4.2.5.3.2 (“Processing After Position Confirmation”). These
specifications are discussed in more detail in section A.6.5 of this Handbook.
A.4.3.5
Conflict Solutions
Once a solution has been confirmed, it is expected that subsequent reports of the same beacon will
continue to point at the same position. However, there are situations where the new solution does
not match the confirmed solution:
• If the beacon is moving, the new solution will reflect the new position of the beacon. For a
moving beacon, the position will normally continue to move as time passes.
• If the new solution is in error, then it will conflict; however, subsequent solutions should
then match with the original confirmed solution.
• If the solutions that generated the original confirmed solution were in error, then the new
solution will eventually be confirmed by a subsequent solution, and the old confirmed
solution will be discarded.
In any case, the conflicting solution will be reported in a special format, so that the receiving MCC
(or RCC) will be aware of the conflict.
A.4.4
Alert Message Contents
Each incident alert message contains a series of message data fields that carry specific items of
information about that alert. Every incident alert message includes the message control fields that
are listed in Table  in section B.4.1 of this Handbook.
The following paragraphs and the tables to which they refer (from section B.4 of this Handbook)
identify the message data fields that are used specifically for incident alert messages. In each of
these tables, the entry under MF \#is the Message Field number, as defined in document C/S A.002,
“Cospas-Sarsat Standard Interface Description” (the SID), that is used to identify that data item.
Note that these tables do not include information about the text or data that may be included in the
SIT 185 or SIT 985 messages.
Many of the solutions generated by the Cospas-Sarsat System produce beacon positions, including
estimates of the longitude and latitude of the beacon. Table  in Annex B of this Handbook identifies
the data items that are contained in the Cospas-Sarsat incident alert data messages.
Of course, each incident is the result of the activation of a beacon, which will be detected and
reported through more than one of the different sub-systems operated by Cospas-Sarsat; in fact,
any active beacon will most likely be detected and processed by all of the Cospas-Sarsat sub-
systems. The “System” column of Table  of this Handbook identifies the data items that apply to
each of the sub-systems. This allocation may only apply to the first detection (depending on the
sub-system by which the beacon was detected and processed first). Subsequent reports will most

A-12

likely include some combination of the features of the individual sub-systems that have contributed
to the generation of the data used in the alert.
Each solution that is generated by the Doppler processing that is performed by the LEOSAR
system consists of two possible positions (usually denoted as the A- and B- locations),
symmetrically placed across the satellite orbit plane. Each of these positions is identified by a set
of data items; two complete sets are used to describe the solution. The data items that are used in
the incident alert messages that are based on beacons detected and processed through the LEOSAR
satellites and the associated LEOLUTs are labelled as “All” or as “LEOLUT” in Table  of this
Handbook.
The MEOSAR DOA processing normally generates a single position estimate with each solution.
The data items that are used in the incident alert messages that are based on beacons detected and
processed through the MEOSAR satellites and the associated MEOLUTs are labelled as “All” or
as “MEOLUT” in Table  of this Handbook.
The GEOSAR system is not able to generate an independent location estimate. The data items that
are used in the incident alert messages that are based on beacons detected and processed through
the GEOSAR satellites and the associated GEOLUTs are labelled as “All” or as “GEOLUT” in
Table  of this Handbook.
A.4.5
Alert Message Routing
Once the destination of the message has been determined, then the MCC must decide on the format
to be used for the message. The available options are:
• If the destination is another MCC, then the appropriate SIT message format should be used,
depending on the nature of the alert data.
• If the destination is a foreign SPOC, then the SIT185 message format should be used. The
details of the contents to be placed in the message will depend on the nature of the alert
data.
• If the destination is a national RCC, then the MCC will use the message format that is
defined by the national Administration for communications with the associated RCC. This
will usually be the SIT 185 message format (or a variant thereof), but it may be a
completely independent message format.
The text of the formatted message, as appropriate, is generated. The incident alert message will
then be transmitted, as specified in document C/S A.001 (Data Distribution Plan) and described in
the appropriate section of this Annex.

A-13

A.4.6
Continued Transmission
The normal procedure for the distribution of alerts is to send every new alert to the destination
authority, unless the new alert is redundant with a previously transmitted alert. However, an RCC
may want to consider not receiving subsequent alerts for the same beacon, for a variety of reasons:
• The RCC may have investigated and determined that this beacon activation is not related
to any real distress incident.
• The RCC may have already dealt with the distress incident signalled by the beacon
activation.
• The RCC may have been in contact with the person(s) in distress and may not require
further information about the incident.
• The RCC (or the MCC) may be aware that a beacon test is planned (or in progress), and
that the RCC does not need to be notified of the test data.
In any of these (or similar) situations, the MCC must be able to suppress the transmission of any
future alert for a given beacon, or from any beacon in a specified area.
Similarly, after the transmission of alert data has been suppressed, the MCC operator may wish to
resume transmission of the suppressed alerts.
For either of these situations, the MCC operator may specify either the identifier of the beacon or
the region where the beacon is located. (The region may be described as either as a circle around
a specified point, or as a range of latitude and longitude values). As each beacon alert is received
and processed at the MCC, the MCC must recognize these situations and distribute the alert (or
not distribute the alert) accordingly.
The specifications for the processing of continued transmission of alerts are contained in
sections 3.2.5 (“Continued Transmission after Position Confirmation”) and 3.2.7 (“Requesting
Transmission of Alerts”) of document C/S A.001. These specifications are discussed in more detail
in section A.5 of this Handbook.
A.4.7
Special Processing
As indicated in section 4.3.4.5 of this Handbook, the normal sequence of incident alert message
processing may have to be changed to meet the special requirements of certain circumstances.
These circumstances may arise because of the nature of the beacon or the contents of the incident
alert message.
Beacons that require special processing include:
• Ship Security Alerting System (SSAS) beacons,
• Return Link Service (RLS) beacons,
• Distress Tracking (ELT(DT)) beacons,
• System Beacons.

A-14

Other situations that may require special processing include:
• Notification of the country where the beacon is registered (as indicated by the country code
in the beacon message),
• Alert cancellation messages.
The special processing for each of these situations is described in the following paragraphs.
A.4.7.1
Ship Security Alert
An SSAS beacon is a beacon that has been designed to report a threat to the ship on which it is
carried. These beacons are designed for manual operation, and they have a special identifier code
that identifies them as SSAS beacons. These beacons are intended for the use of ships that may be
under attack, from pirates, hijackers, or other enemies. While these incidents are true distress
incidents, they are not the sort of incidents that the Search and Rescue (SAR) forces of an RCC
are prepared to address.
These incident alert messages are not sent to the SAR forces. Instead, they are sent directly to a
competent authority, which has been designated by the administration of the country in which the
SSAS beacon is registered (and whose country code is encoded in the beacon message), for action.
This enables the authorities in that nation to address the issue.
The specifications for the processing of SSAS alerts are contained in section 4.2.8 (“Distribution
of 406 MHz Ship Security Alerts”) in document C/S A.001. Document C/S A.002 contains the
specifications for the message formats that are used to transmit the alert data for an SSAS beacon;
these formats are discussed in more detail in section B.5.9 of this Handbook.
A.4.7.2
Return Link Service Alert
The Return Link Service (RLS) is a special service that is offered by some MEOSAR Space
Segment Providers, who are also the operators of Global Navigation Satellite Systems (GNSS). It
offers the capability to send messages to beacons that support the RLS capability via the navigation
downlink signals from their GNSS satellites. Cospas-Sarsat supports the use of this service for the
transmission of Type-1 acknowledgement messages to active distress beacons. The Type-1
acknowledgement message is intended to acknowledge that the distress alert has been detected by
the Cospas-Sarsat System; it is not intended to provide any assurance that the alert has been
received by an RCC or that any action has been taken on that alert message.
The illustration in Figure A.2 shows the flow of data for the generation of the Type-1
acknowledgement when an alert is received from an RLS beacon. When the responsible MCC
receives an alert from an RLS beacon, it generates a Return Link Message (RLM) request that is
sent to the MCC associated with the Return Link Service Provider (RLSP); this information is
used by the RLSP to trigger the generation of the Return Link Message (RLM) to the beacon.

A-15

Figure A.2: Return Link Service
This illustration shows the flow of data for an alert from an RLS-capable beacon.
At the present time, the following GNSS support an RLS capability:
• SAR/Galileo (Interim Operational Capability),
• SAR/Glonass (planned),
• SAR/Beidou (planned).
The operator of each of these GNSS services is required to designate an MCC that should be
notified when an incident alert is received from an RLS beacon; this designated MCC is to be
notified of the alert by the MCC that sends the incident alert message to the responsible RCC or
SPOC. The designated RLS support MCC is then responsible to interface with the GNSS operator
to notify it of the beacon activation, with an estimated beacon location. Based on this information,
the GNSS operator can then send the response message to the beacon.
A distress beacon that supports the RLS is encoded with a digital message in a special format, as
defined in the appropriate beacon specification document (document C/S T.001 or C/S T.018).
When a message is received at an MCC from an RLS-capable beacon, it is processed in the same
way as any other distress alert; the only exception is that, in addition to the normal distress alert
message, the MCC also forwards that incident alert message (in a special format defined in C/S
A.002) to the MCC that supports the Return Link Service Provider (RLSP). The RLSP associated
with each operational RLS is identified in Table 4-16 (“Associated MCCs for Return Link Service
Providers”) of C/S A.001.

![Image 1 from page 152](/images/cospas-sarsat/G-series/G010/G010_page_152_img_1.png)

A-16

When the MCC that supports the RLSP receives an RLS message, it notifies the RLSP that the
alert has been received and processed by the Cospas-Sarsat System. The RLSP then takes the
necessary action to generate and transmit the Type-1 acknowledgement message to the beacon.
An RLS beacon is equipped with a means to notify the user when the acknowledgement message
is received at the beacon.
It should be noted that the Type-1 acknowledgement is only intended to indicate that the alert has
been received by the Cospas-Sarsat System and forwarded to the appropriate RCC. It does not
confirm that the RCC has received the alert message, nor does it otherwise indicate that any action
has been (or is being) taken towards a rescue. However, it does provide some reassurance that the
occurrence of the distress incident has been reported, and some hope that help will come. (A Type-
2 acknowledgement, which has been proposed by the European Commission for use with their
Galileo GNSS, but which is not currently implemented in the Cospas-Sarsat System, would be
generated on the initiative of the RCC, and would indicate that the RCC is taking action towards
the rescue of the persons in distress.)
The final MCC in the alerting chain (that is, the MCC that is responsible for sending the incident
alert message to the RCC or SPOC) is the one that is required to notify the MCC that has been
designated by the GNSS operator. While this may result in more than one alert going to the
designated MCC (especially if the location of the distress incident moves from one MCC Service
Area to another), it is intended to minimize the duplication of these messages. Note that the RLS
operator notification message is sent in addition to the normal distress alerting messages. Those
incident alert messages will continue to be formatted and transmitted to the appropriate destination,
independently of the RLS notification message.
Once the RLSP has been notified of the activation and detection of the RLS beacon, the Cospas-
Sarsat MCC does not perform any other special processing of future messages from that activation
of the beacon.
The specifications for the processing of RLS alerts are contained in section 4.2.10 (“Return Link
Service (RLS) Procedures”) of document C/S A.001. Document C/S A.002 contains the
specifications for the message formats that are used to transmit the alert data for an RLS beacon;
these formats are discussed in more detail in section B.5.10 of this Handbook.
A.4.7.3
Distress Tracking ELT Alert
As explained in section 2.2.1.1 of this Handbook, ICAO is developing a Global Aeronautical
Distress and Safety System (GADSS). The requirements for the GADSS are specified in various
amendments to the Annexes to the Chicago Convention, and in other documents such as ICAO
document 10054, “Manual on Location of Aircraft in Distress and Flight Recorder Data
Recovery”.
Among other things, the GADSS requires that all commercial aircraft must carry a device that will
provide information, at one-minute intervals, at any time the aircraft is in a potential distress
situation; that is, a situation which if continued is likely to lead to an accident. The details of the

A-17

conditions that may indicate the potential distress situation and trigger the beacon are outside the
scope of Cospas-Sarsat; they may include such things as:
• Ground proximity indication,
• Loss of engine power,
• Unusual aircraft attitude.
The actual indications are specified in the document ED-237, issued by the European Organisation
for Civil Aviation Equipment (EUROCAE). Regardless of these details, the intent is that the
beacon should provide sufficient information that the aircraft operator (in ICAO terminology, this
is the airline that operates the airplane) should be able to determine the position of the aircraft after
a crash with an accuracy of six nautical miles (approximately eleven kilometres).
In support of this ICAO initiative, Cospas-Sarsat is developing the specifications for a distress
tracking ELT: an ELT(DT). An ELT(DT) beacon will be encoded with a digital message in a
special format, as defined in the appropriate beacon specification document (document C/S T.001
or C/S T.018).
The illustration in Figure A.3 shows the support that is provided by the Cospas-Sarsat data
distribution system when an alert is received from an ELT(DT) beacon.
Figure A.3: Distress Tracking Alert Support
This illustration shows the support that Cospas-Sarsat provides for an alert from a Distress Tracking
beacon.

![Image 1 from page 154](/images/cospas-sarsat/G-series/G010/G010_page_154_img_1.png)

A-18

When an MCC receives an alert message that is from an ELT(DT) beacon, it will be processed in
the same way as any other distress alert, with some exceptions:
• The incident alert data will be written to a separate database, the Location of Aircraft in
Distress Repository (LADR), operated by (or for) ICAO, so that the data is available to any
of the interested parties:
-
The airline that operates the aircraft that may be in distress,
-
the Air Traffic Service Unit(s) (ATSU), such as Air Traffic Control centres, that may
be in contact with the aircraft,
-
The Rescue Coordination Centre that may have to respond to the accident if (or when)
it happens,
-
Other responsible parties that may be authorized by the administration of the country
where the beacon has been located,
-
Other responsible parties that may be authorized by the administration of the country
where the beacon has been registered.
• The rules for determining when a detection is redundant will be relaxed, to ensure that
every ELT(DT) alert is forwarded through the data distribution system to the LADR and
to the responsible RCC.
• The alert will be sent to the RCC or SPOC in a special variation of the SIT 185 format, so
that it will be recognized as an alert of a potential distress (as distinct from an actual
airplane crash report).
Beyond these amendments, an incident alert from an ELT(DT) is processed in the same way as
any other distress alert and is sent to the RCC using the normal data distribution procedures.
ICAO has not yet (in  mid-2023) completed implementation of the LADR. However, plans call for
nodal MCCs to provide the data on ELT(DT) activations to the LADR in the ICAO-specified
format.
The specifications for the processing of ELT(DT) alerts are contained in document C/S A.001, in
Figure 3-2 (“406 MHz Alert Data Distribution Procedures - ELT(DT)s”), in section 3.2.3.2.2
(“Filtering of Redundant Data for ELT(DT)s”), in section 3.7.10 (“Operational Distribution of
Alert Data for SGBs and FGB ELT(DT)s”), and in section 3.12 (“Autonomous Distress Tracking
Data Repository for ELT(DT) Alert Data”). Document C/S A.002 contains the specifications for
the message formats that are used to transmit the alert data for an ELT(DT) beacon; these formats
are discussed in more detail in section B.5.10 of this Handbook.
A.4.7.4
System Beacons
A System Beacon is any 406 MHz beacon that is designed for use other than as an operational
distress beacon. These beacons are encoded with unique identifiers, so that they will be recognized
as orbitography beacons, MEOSAR calibration beacons, reference beacons, test beacons, or

A-19

beacon simulators. These beacons are all intended to be used to support the operation of the
Cospas-Sarsat System. Among other uses:
• Calibration beacons support the operation of some part of the Cospas-Sarsat System:
-
Orbitography and reference beacons are used for the computation of accurate orbit
ephemeris data for operational satellites.
-
The T-Cal beacons and reference beacons are used for the calibration of the data
processing for a Cospas-Sarsat LUT:
▪
Sarsat LEOSAR SARP frequency reference,
▪
Sarsat LEOSAR SARP time reference,
▪
SARR frequency reference.
-
MEOSAR calibration beacons and reference beacons are used for the calibration of
the MEOSAR system processing:
▪
At least one reference beacon near the edge of each MEOLUT Designated
Coverage Area (DCA) or at least one thousand kilometres from the MEOLUT,
▪
Technical parameters as defined in C/S A.003 (section 2.3.2.1, “Designated
QMS Reference Beacons”),
▪
Coordinated regionally to maximize the usability and to minimize the impact on
System operations.
• Beacon simulators and test beacons support the performance of tests of some part of the
Cospas-Sarsat System:
-
Beacon tests, including beacon type-approval tests,
-
LUT tests, including LUT commissioning tests,
-
MCC tests, including MCC commissioning tests,
-
Tests of the capabilities of an RCC or another rescue service.
• Reference beacons support the Quality Management System (QMS) assessment of the
capabilities of the Cospas-Sarsat System:
-
The reference beacons at McMurdo and Longyearbyen are used to confirm the
continuous monitoring capabilities of the LEOSAR system,
-
The reference beacons at Toulouse, Edmonton, and Kerguelen are used to confirm the
continuous monitoring capabilities of the GEOSAR system,
-
The designated reference beacons (as defined in C/S T.022 and C/S A.003) transmit
special sequences of messages to mimic beacon events.
• System beacons support the demonstration of the capabilities of the Cospas-Sarsat System
-
System Demonstration and Evaluation Programs,
-
More comprehensive System tests or System exercises.

A-20

In the beacon specification documents C/S T.001 and C/S T.018, special beacon identifiers are
reserved for these orbitography and test beacons.
In order to avoid conflicts in the assessment of the System, beacons that are used for calibration
of one or more System elements may not also be used as a designated QMS reference beacon. A
list of reference beacons that are available for System calibration and for QMS evaluation is
available on the Cospas-Sarsat website.
When an alert is received from a test or reference beacon, the processing will be different from the
normal beacon message processing:
• If the beacon has been designated for use as a QMS reference beacon, then the solution
data associated with this detection is sent directly from the LUT to the associated MCC. It
may be kept locally in the MCC or may be forwarded to the nodal MCC, for use in
evaluating the performance of the System.
• If the beacon has been designated for use as an orbitography beacon, the data will be used
internally in the LUT to update the orbital elements of the satellite that relayed the beacon
signal to the Ground Segment. In this case, the MCC will not forward the beacon data to
any other MCC, SPOC, or RCC.
• If the beacon has been designated for use as a calibration beacon, the data will be used
internally in the LUT to update the appropriate calibration data for the satellite that relayed
the beacon signal to the Ground Segment. In this case, the MCC will not forward the beacon
data to any other MCC, SPOC, or RCC.
• If the beacon has been designated for use during a system test, then the processing will
depend on the requirements of the specific test that is planned. In such a case, the beacon
identifier(s) will be sent to all MCCs in advance of the test, and instructions for the
distribution of the data collected from these beacons will normally be included in the Test
Plan. The data may be:
-
Distributed as normal incident alert data,
-
Sent to a specific designated MCC for evaluation,
-
Analyzed (according to the requirements of the Test Plan) at each MCC,
-
Stored for future analysis, but not distributed through the Cospas-Sarsat System.
Depending on the nature of the test, some or all MCCs may be expected to participate in
the test, and to collect and process the data from the reference beacons.
The flow of data from the designated MEOSAR QMS reference beacons to the nodal MCC, where
the data is processed and the results are published, is illustrated in Figure A.4.
For more detailed information about the MEOSAR reference beacons:
• The detailed technical requirements for each MEOSAR reference beacon are specified in
C/S T.022, “Cospas-Sarsat MEOSAR Reference Beacon Network Design Guidelines”.

A-21

• A list of the designated reference beacons that are used by each MEOLUT is provided in
the MEOLUT Commissioning Report for that MEOLUT.
• A summary of the technical parameters of each operational MEOSAR reference beacon is
available on the Cospas-Sarsat website.
The specifications for the processing of reference beacon alerts are contained in the text in
section 2.3.2.1 (“Designated QMS Reference Beacons”) of document C/S A.003, “Cospas-Sarsat
Monitoring and Reporting”. Document C/S A.002 contains the specifications for the message
formats that are used to transmit the alert data for any beacon; these alerts for test and reference
beacons are normally transmitted in the same message format as any normal incident alert
message. These message formats are discussed in more detail in Annex B of this Handbook.”
Figure A.4: Flow of Cospas-Sarsat QMS Data
This illustration shows the flow of data from the designated Cospas-Sarsat MEOSAR QMS reference
beacons through the Ground Segment to the nodal MCCs for evaluation.
A.4.7.5
Notification of Country of Registration Alert
An incident alert message will normally be sent to the MCC whose Service Area includes the
location where the beacon has been located. However, if the beacon message contained in the alert
data includes a valid country code, then the incident alert message will also be distributed to the

![Image 1 from page 158](/images/cospas-sarsat/G-series/G010/G010_page_158_img_1.png)

A-22

country that is identified in the beacon message, as a Notification of Country of Registration
(NOCR) message. This provides the authorities in that country with the knowledge of any distress
situation that may involve their own nationals and enables them to offer the local authorities any
assistance that may be appropriate under the circumstances. Although the NOCR message is not
officially a request for beacon registration data, the receiving MCC may wish to respond by
sending the available registration data to the originating MCC or to the RCC that will be
responsible for the SAR response to the reported incident.
If the country is included in the Service Area of this MCC (as identified in a configuration file in
the MCC), then the incident alert message will be transmitted to the appropriate RCC or SPOC.
Otherwise, the incident alert data will be sent to the associated nodal MCC, which will determine
the appropriate onward distribution.
The NOCR message is in addition to any other incident alert message that may be generated by
the system. However, if a distress alert message has already been sent to the country of registration,
then a separate NOCR message would be redundant, and will not be sent.
Once the destination has been established, the message format will be decided (as described above,
but using the appropriate NOCR message format), and the message text will be generated. The
incident alert message will then be transmitted, as described in section A.5 of this Handbook.
The specifications for the processing of NOCR alerts are contained in section 4.2.7 (“NOCR
Procedures”) of document C/S A.001. Document C/S A.002 contains the specifications for the
message formats that are used to transmit the alert data for notification of the country of
registration; these formats are discussed in more detail in section B.5.8 of this Handbook.
A.4.7.6
Cancellation Message
Some distress beacons include a capability for the user of the beacon to cancel the alert; this is
done by the transmission of a special cancellation message from the beacon. A cancellation
message indicates that there is no distress incident in progress. This may be because the beacon
was triggered by accident (and there was never a distress incident) or because the distress incident
that triggered the beacon has cleared up and assistance is no longer required. This capability is
required (in ICAO document 10054, “Manual on Location of Aircraft in Distress and Flight
Recorder Data Recovery”) of all ELT(DT) beacons, and it is available to the manufacturers of all
second-generation beacons. To ensure that a cancellation message is not received and processed
in error, the specifications require that several consecutive cancellation messages be sent by the
beacon, and that more than one such message must be received before they will be processed.
When the first cancellation message is received at an MCC, the MCC sets a flag and waits for
another cancellation message from the same beacon. If any other message is received from that
beacon, the flag is cleared, and no further action is taken. However, if further cancellation
messages are received, then the MCC sends a cancellation alert to all the RCCs that have been
notified of the original distress alert. Each RCC can then process this cancellation alert according
to its own procedures.

A-23

The specifications for the processing of cancellation message alerts are contained in section 4.2.11
(“Cancellation Message Procedures”) of document C/S A.001. The standard alert message formats
(as defined in the SID and discussed in section B.5 of this Handbook) are used to transmit
cancellation alert data messages. These messages are recognized by the contents of the beacon
message that is contained in the incident alert message.
Once a cancellation message has been recognized at an MCC, a new incident alert message, which
can be identified as a cancellation message, is transmitted to every destination to which the MCC
has previously sent an incident alert for that beacon. The SIT 185 message that is sent to the final
SAR destination contains an explicit statement that this is a cancellation message.
A.5
Message Transmission
Once the alert data has been prepared in the format that is appropriate for the nature and contents
of the alert, the MCC must determine the network that will be used to communicate with the
selected destination. This is normally established by a configuration setting in the MCC.
The formatted message string is wrapped in the header and trailer sequences that are required by
the network, which may include:
• an indication of the start of message (unique to each network protocol),
• the addressing data appropriate to the selected destination,
• a message sequence number (which can be used at the destination to ensure that no message
has been lost since the previous message was sent),
• information about the message priority,
• any other data that may be required by (or available through) the selected communications
protocol,
• an indication of the end of the message packet.
With this data included, the message is transmitted over the network.
If the network protocol supports it, the reception of the message by the destination will be
confirmed automatically by the software. Otherwise, the message is simply transmitted, and the
successful reception is assumed.
A.6
Data Validation
A.6.1
406 MHz Alert Message Validation
Section 4.2.1.1 (“Validation of Alert Message Format and Content”) of the DDP requires that each
MCC should validate all incoming beacon alert messages based on the format and content of the
SIT message. The flow chart in Figure 4-8 of the DDP (“406 MHz Alert Message Validation
Flowchart”) illustrates the alert message validation processing.

A-24

A message is considered corrupt if:
• any message field is missing; or
• the size of any message field is incorrect; or
• a numeric message field contains non-numeric character(s); or
• a space or decimal point is incorrectly placed.
If the message is corrupt, then all processing of that message is suppressed. Otherwise, the message
is processed according to the requirements of Table 4-4 (“406 MHz Alert Message Validation”)
of the DDP.
If the message is not corrupt (based on the characteristics listed above), then a further check of the
contents of the essential message fields is required. These essential message fields are included in
Table  and are identified explicitly in Table . If the values of all of these message fields are within
the allowed range (as specified in the SID), then the message can be processed; if any of these
values is out-of-range, then the message is considered to be corrupt, and the processing must be
suppressed.
Table A-4: Essential Message Fields
The Message Fields that are listed in this table are considered essential, and their contents must be
evaluated to ensure that they are within the expected range before the message can be accepted as a
valid message.

A-25

MF \#
Name

Reporting facility

SIT

Spacecraft ID

Number of Alerts with Doppler/DOA Positions

Number of Alerts without Doppler/DOA Positions

Source ID

Local or Global Flag & Frequency Band

Bias, BSDEV, & Drift

TCA
14a
Time of First Burst
14b
Time of Last Burst

Number of Points or Bursts

FGB 406 Message

Latitude

Longitude

Error Ellipse

Data Residual

FGB Full 406 Message

Satellite IDs

SGB Data
The list of items that must be checked, together with the bit position of each item in the beacon
message and the pass/fail criteria for each item, are contained in Table 4-6 (Protocol Validation
for 406 MHz Alert Messages) of the DDP. This validation is further described in sections 4.2.1.1.4
(406 MHz FGB Message Validation) and 4.2.1.1.5 (“406 MHz SGB Message Validation”) of the
DDP. The validation of the message fields that contain the beacon message data (MF \#23, 77, and
90) is based on the appropriate beacon specification.
The MCC must also verify that the position reported for the beacon was visible to the satellite(s)
through which the beacon data was received at the time when the detections were reported. This
is done by computing the visibility circle of each satellite and confirming that the estimated
position is inside that circle. See section 4.2.1.2 (“Doppler/DOA Position Footprint Validation”)
of the DDP (document C/S A.001) and Appendix B.2 to Annex B (“Determining the LEOSAR
Image Position and Validating the Satellite Footprint”) of the SID (document C/S A.002).
Finally, the DDP requires, in section 4.2.1.4 (“Uncorroborated MEOSAR Alerts”), that the MCC
make a special check for uncorroborated MEOSAR alerts; that is, any alert that has been derived
from only a single beacon burst (i.e., the associated detect times per Message Fields \#14a and \#14b

A-26

in document C/S A.002 are within 2.5 seconds) and from a single satellite (per Message Field \#83)
for which no previous alert has been generated for this beacon activation that contains data from a
different beacon burst or satellite. This is a temporary measure to eliminate the large number of
spurious solutions that were reported by the first MEOLUTs developed for use with the System.
A.6.2
Concept of Filtering Redundant Data and Better-Quality Alerts
Although the rules described in the previous sections are generally applied, there are some
exceptions that are allowed in document C/S A.001, “Cospas-Sarsat Data Distribution Plan (the
DDP):
• Unless continuous transmission has been requested (as described below), then redundant
data (that is, repeat data for the same detection of the same beacon incident) will not be
sent to any MCC or RCC. The detailed rules for determining when incident alert data is
redundant are fairly complex and are described in detail in section 3.2.3.2 (“Filtering of
Redundant Data”) of the DDP.
• A solution that is not redundant will not be distributed unless it is a better-quality solution
that any of the previously transmitted solutions. The details of this processing are described
in section 4.2.4 (“Procedures to Determine Better Quality LEOSAR Alert Data for Same
Beacon Event Position Conflicts”) of the DDP.
• Any MCC can request continuous transmission of incident alert messages for a specified
beacon or for a specified area, as explained in section 3.2.5 (“Continued Transmission after
Position Confirmation”) and section 3.2.7 (“Requesting Transmission of Alerts”) of the
DDP. This can be done for a known beacon, in advance of any alert being received (in
support of a traveller who may have special reasons to request this monitoring), or in
support of a planned test. In this case, every incident alert for the specified beacon will be
sent to the requesting MCC or RCC.
• Any MCC can request the suppression of incident alert messages for a specified beacon or
for a specified area as explained in section 3.2.7 (“Requesting Transmission of Alerts”) of
the DDP. This can be done for a known beacon, in advance of any alert being received (in
support of a traveller who may have special reasons to request this monitoring), or in
support of a planned test. In this case, no incident alert messages for the specified beacon
will be sent to the requesting MCC or RCC.
These rules are designed to prevent overloading of the communication networks and the MCC
processing capabilities (and the demands on the MCC operators) when the system becomes busy.
A.6.3
Event Flags
The processing of an incident alert is controlled by a series of flags, as defined in section 4.2.5.4.1
(“Tests and Flag Setting for Special Processing Procedures”) of the DDP. The precise definitions
of these terms are contained in that section, but the following are general descriptions of some of
these flags:
• SBE (Same Beacon Event):

A-27

A beacon event is defined (in document C/S S.011, “Cospas-Sarsat Glossary”) as the
passage of a Cospas-Sarsat satellite over an active beacon, characterized by the time of
closest approach (TCA) and the satellite identification.
Two LEOSAR Doppler solutions represent the same beacon event (SBE=1) if they are
based on the same satellite and their TCAs are within twenty minutes of one another.
Otherwise, the flag is set to 0.
This flag is only used for matching two Doppler solutions; for any other matches, the flag
is set to the default value (0).
This flag is used to decide when a new LEOSAR Doppler solution can be used to confirm
a previously received Doppler solution and to resolve the solution ambiguity, as explained
in section 4.3.4.4 of this Handbook and in section C.1.2.1 of this Handbook. The distance
criteria for matching the two events are described in section A.6.4 of this Handbook.
• DBE (Dependent Beacon Event):
Two MEOSAR DOA solutions represent a dependent beacon event (DBE) if the new
solution is based on the same set of satellites (or a subset thereof) over the same time period
(within thirty minutes). Once a solution has been confirmed, the criteria for a dependent
beacon event are similar but somewhat different, depending on whether or not the new
solution matches the confirmed solution.
• PQF (Poor Quality Flag):
A LEOSAR Doppler solution is of poorer quality that the previous solution if the expected
error estimate indicates that the initial solution was expected to be closer to the true beacon
position.
The PQF is not used for a MEOSAR DOA solution. (It is always set to indicate a poorer
quality solution.
These flags are used to control the processing of each new incident alert message, as determined
by the special processing matrices in the remaining parts of section 4.2.5.4 (“Special Processing
Procedures”) of the DDP.
Each of the special processing matrices is based on a particular incident status, and indicates the
desired processing, based on the various combinations of processing flags and input solution status.
The structure of these processing matrices is explained in section A.3 of this Handbook.
A.6.4
Distance Criteria
The DDP (document C/S A.001) specifies many distance criteria to be used for the automatic
processing of incident alert location data:
• There are separate match criteria for each combination of solution types, as defined in
section 4.2.2 (“Position Matching”) of C/S A.001 and listed in Table  of this Handbook.
• There are distance criteria for the decision of when to transmit a better-quality position
estimate for a DOA solution, as defined in section 3.2.3.2.3 (“Distribution of Alerts with
Better Quality DOA Position”) of C/S A.001 and listed in Table  of this Handbook.

A-28

• There is a distance criterion of 100 km for the matching of interferer solutions, as defined
in section 4.2.9.1 (“406 MHz Interference Data Processing”) of C/S A.001.
The use of each of these criteria in the incident alert processing in the MCC is described in the
DDP.
In general, each distance match criterion is required to be independently configurable; this allows
for future changes to individual distance match values without the need for a modification to the
MCC software.
If more than one position is available for the matching test, then the best match shall be used to
confirm the position. These are two-dimensional distance criteria; the altitude is not to be used in
computing the distance between two positions.
As explained in section C.1.2.1 of this Handbook, two LEOSAR solutions that match on both sides
(A- and B- positions) cannot be used to resolve the solution ambiguity.
Table A-5: Solution Match Criteria
This table lists the criteria that are used for matching two beacon position estimates, as defined in
section 4.2.2 of C/S A.001.
Solution Types
Match Distance
(kilometres)
Doppler
Doppler

Doppler
Encoded

Encoded
Encoded

DOA
DOA

DOA
Encoded

DOA
Doppler

As defined in section 3.2.4 (“Confirmation of Beacon Positions”) of C/S A.001, the same position
matching criteria listed in Table  of this Handbook are used for the confirmation of a beacon
position estimate.
When the MCC has determined that a new solution is a better quality than a previous solution, the
new message will be transmitted if it meets the criteria listed in Table  of this Handbook. In
addition, the EHE of the new position must be at least 50% less than the lowest EHE for all
previously reported solutions.
Table A-6: Better Quality Solution Criteria
This table lists the criteria that are used in the determination of which of two MEOSAR solutions
gives a better-quality position estimate, as defined in section 3.2.3.2.3 of C/S A.001.

A-29

Solution Types
Maximum
Distance
(nautical miles)
Maximum
Distance
(kilometres)
New Solution EHE
150.0
277.8
Minimum difference (FGB)
2.0
3.704
Minimum difference (SGB)
1.9
3.519
A.6.5
Image Position Determination
As explained in section 4.2 of this Handbook, every LEOSAR Doppler solution produces two
position estimates, of which one points at the real position of the beacon and the other points at an
image (the reflection of the position across the satellite orbital plane. The process of determining
which is the image solution (and which is, therefore, to be discarded) is called ambiguity
resolution. Ambiguity resolution is explained in more detail in section C.1.2 of this Handbook.
A.6.6
Satellite Footprint Verification
At any given time, each satellite can only see a limited part of the surface of the Earth; this area of
the Earth’s surface is the footprint of the satellite. Each location that is received by the MCC must
be verified to ensure that it is consistent with the position of the satellite. That is, the location must
be within the footprint that was visible to the satellite at the time when the data for that location
was collected.
The details of the footprint validation are described in Appendix B.2 to Annex B (“Determining
the LEOSAR Image Position and Validating the Satellite Footprint”) of the SID (document
C/S A.002). If a location fails the footprint validation check, then it should be flagged as unreliable,
as specified in sections 4.2.1.2 (“Doppler/DOA Position Footprint Validation”) or 4.2.1.3
(“Encoded Position Footprint Validation”) of the DDP (document C/S A.001). In summary:
• An independent position (Doppler or DOA location) that fails the footprint check may be
used, but must be flagged as suspicious in the message that is sent out with this alert by the
MCC,
• An encoded location that fails the footprint check must not be used in the MCC processing
of the alert.
Note that, as explained in section 6.10 of this Handbook, the footprint check requires that the MCC
have orbital data available for each of the satellites that is used by the Cospas-Sarsat Space
Segment.
A.6.7
Bit Errors
The Cospas-Sarsat System includes several digital communications systems:
• the uplink from the distress beacon to the satellite of the Cospas-Sarsat Space Segment,
• the downlink from the spacecraft to the LUT of the Ground Segment,

A-30

• the communications link from the LUT to the associated MCC,
• the communications links among the MCCs that comprise the data distribution system,
• the communications link from the destination MCC to the SAR destination that will finally
deal with the distress situation.
Any digital communications system may be subject to errors, which will result in bit errors in the
data: invalid data bits that may be present in the received message.
A.6.7.1
Satellite Link Errors
Any bit errors that are generated in the uplink or downlink communications links through the
Cospas-Sarsat spacecraft are dealt with when the beacon message is received at the LUT. The
beacon specifications (documents C/S T.001, C/S T.015, and C/S T.018) all include provision for
a Bose–Chaudhuri–Hocquenghem (BCH) error correcting code (ECC).
The BCH codes can identify bit errors in a message, and they can be used to correct the message
if the number of errors is sufficiently small (as indicated in Table ). As long as the number of bit
errors is small enough, the same computations can be used to identify the bits that have been
corrupted in the received message and to correct the message. The details of the computations that
generate the BCH codes are described in Annex B (“BCH and CRC Calculations”) to the first-
generation beacon specification (document C/S T.001) and in Appendix B (“Sample Bose-
Chaudhuri-Hocquenghem Error-Correcting Code And 23 Hex ID Calculations”) to the second-
generation beacon specification (document C/S T.018).
Table A-7: Bit Error Detection and Correction
This table indicates the number of bit errors that can be detected and corrected by the various BCH
codes that are used in the Cospas-Sarsat distress beacon messages.
Message Types
Bit Errors
Detected
Corrected
FGB Message


FGB Extension


SGB Message


A.6.7.2
LUT to MCC Errors
As noted in section 4.4.2.2 of this Handbook, Cospas-Sarsat does not specify the communications
link between each LUT and its associated MCC. However, the MCC Performance Specification
(in C/S A.005) does require (in section 5.2.1, “LUT/MCC”) that less than 0.1% of all messages be
lost in transfer. It also imposes time limits for the completion of transmission of alert data from
the LUT to the MCC.
Most LUT to MCC communications links are digital data networks that include their own
capability to detect and to correct any errors that occur during the transmission of the data from
the LUT to the MCC. In practice, all MCCs meet the requirements (above) without difficulty.

A-31

A.6.7.3
MCC to MCC Errors
The communications links between MCCs are required to meet the specifications of the DDP
(document C/S A.001) and the SID (document C/S A.002). In addition, the MCC Performance
Specification (in C/S A.005) requires (in section 5.2.2, “MCC/MCC”) that less than 0.1% of all
messages be lost in transfer. It also imposes time limits for the completion of transmission of alert
data from the LUT to the MCC and an availability requirement for each communications link.
The FTP/VPN communications links that are used by most MCCs are digital data networks that
include their own capability to detect and to correct any errors that occur during the transmission
of the data. In practice, most MCCs meet the requirements (above) without difficulty. However,
not all parts of the world are well served by the Internet; in these areas, some MCCs have been put
out of service for extended periods of time by communications failures.
In areas where reliable Internet service is not available, some MCCs have chosen to use the AFTN
network. This has created its own problems, as the AFTN (or AMHS) service may be slower than
FTP. Also, since AFTN does not always include error detection and correction, it may be less able
to meet the requirements for Cospas-Sarsat MCC to MCC communications.
The selection of the communications service to be used for inter-MCC communications is a key
decision in the establishment of an MCC, which must be carefully considered to ensure that the
new system will meet the performance requirements for a Cospas-Sarsat MCC.
A.6.7.4
MCC to RCC Errors
As noted in section 4.4.2.3 of this Handbook, Cospas-Sarsat specifies the communications link
between an MCC and its foreign SPOCs, but not its national RCCs. However, the MCC
Performance Specification (in C/S A.005) does require (in section 5.2.3, “MCC/Non-MCC Alert
Recipient”) that this link should be available for 95% of each calendar day. There are no explicit
specifications for the error rate on this link; that is considered a requirement for the receiving end
of the link.
A.6.7.5
MCC Bit Error Processing
When an MCC receives an incident alert, one of the initial steps in the processing is to validate the
alert, as described in section A.1.5 of this Handbook. One of the key steps in this validation is to
confirm that the beacon message, including the BCH code, is correct. If the SIT message is not
valid, the MCC operator should contact the MCC that sent the message and request a re-
transmission. If the beacon message cannot be corrected or is otherwise determined to be invalid,
then the alert will be processed, but the data that is contained in the beacon message will not be
used to control that processing.
A.7
System Data Distribution
System Data is the information that is required by the various components of the Cospas-Sarsat
Ground Segment to ensure that they are able to perform the functions that are required of them.
The System Data messages also include the narrative messages that are used to send status and

A-32

other information between MCCs. Table  contains a summary of the system data and of the SIT
message formats and data fields that are used for the distribution of system data. (Note that the
system data messages also contain many of the control and identification message fields that are
listed in Table , in addition to the message fields that are listed in Table .)
Table A-8: System Data
This table summarizes the system message formats and the data fields that are specific to these
System Messages.
System Data
SIT Message
Numbers
References
Message Fields
Satellite orbits
215, 216, 217
A.7.2
34, 35, 36, 85, 86
SARP Calibration
415, 417
A.7.3.1
37, 38, 38a
SARR Calibration

A.7.3.2
64, 65, 66
Spacecraft Instrument
Control Messages
416, 425, 435, 445,
515, 525, 535, 545
A.7.4
39, 40, 41
Status and narrative
605, 915
A.7.5

Beacon registration
925, 926, 927
A.7.6
94, 95, 96, 97
Each MCC normally maintains a set of orbital and calibration data for each of the satellites that is
tracked by the Cospas-Sarsat Ground Segment. This data is distributed through the MCC network
by the MCC of the Space Segment Provider that is responsible for that part of the Cospas-Sarsat
Space Segment.
The MCC may not actually use this data internally, but it is responsible to ensure that its associated
LUTs have all of the necessary data kept up to date at all times. When an MCC receives a System
Data Message that contains satellite orbit or calibration data, it should validate the data (by
comparing it with the data it already has). If the new data is within an acceptable tolerance of the
old data, then the MCC should accept the new data. If the new data is significantly different from
the old data, then the MCC operator should be notified. The operator will then evaluate the
difference and determine whether the new or old data should be used. Normally, if the associated
LUTs have been using the old data and producing results that are within the accepted tolerances
(as determined by the QMS monitoring), then the MCC should continue to use the old data.
However, if the data produced by the LUTs has been of poor quality, then the operator should
force the MCC to use (and send to its associated LUTs) the new System Data.
Where the text below indicates that the System Data is to be forwarded to associated LUTs, this
only applies if the MCC has one or more associated LUTs of the indicated type.
A.7.1
System Data SIT Message Formats
The System Data Messages that are listed in Table  are described in more detail in the following
sections of this Handbook.

A-33

A.7.2
Satellite Orbit Messages
There are several different message formats for the transmission of satellite orbital data:
• The SIT 215 messages contain the orbit data for the LEOSAR satellites, in the form of
position and velocity vectors. They are sent to all MCCs for the normal distribution of this
data. They should be sent by each MCC to all of its associated LEOLUTs. They may be
used, as required, by each LEOLUT, to update its orbit data. However, if the LEOLUT is
automatically updating its own internal orbit data, based on the data received from
reference beacons and the satellite downlink carrier, then it may use the data that it receives
from the MCC only to verify the internal orbit data.
• The SIT 216 messages contain the orbit data for the LEOSAR satellites, in the form of
position and velocity vectors. They are sent to all MCCs for the distribution of LEOSAR
satellite orbital elements after a satellite manoeuvre. They should be sent by each MCC to
all of its associated LEOLUTs. Regardless of the results of the orbit data validation in the
MCC, these elements are to be used by each LEOLUT to update its orbit data, to ensure
that the orbits have been correctly updated after the completion of the manoeuvre.
• The SIT 217 messages contain the orbit data for the MEOSAR (or any other) satellites, in
the Two-Line Element (TLE) format developed by the North American Air Defence
Command (NORAD). They are sent to all MCCs for the normal distribution of this data.
They should be sent by each MCC to all of its associated MEOLUTs. They may be used,
as required, by each MEOLUT, to update its orbit data. However, if the MEOLUT is
automatically updating its own internal orbit data, based on the data received in the GNSS
navigation downlink signals, then it may use the data that it receives from the MCC only
to verify the internal orbit data.
Although the GEOLUT systems may not require the use of satellite orbital data, this data may be
distributed in the SIT 217 message format and forwarded by each MCC to its associated
GEOLUTs.
The orbit data in these messages may be formatted as either of:
• position and velocity coordinates in a three-dimensional (X-Y-Z) Euclidean coordinate
system,
• a variation of the classical Keplerian orbit elements, in the NORAD Two-Line Element
(TLE) format.
The SIT message formats and the data message fields that are used to transmit the orbit data are
described in more detail in section B.6.1 of this Handbook.
A.7.2.1
Position and Velocity Vectors
The position and velocity vectors provide the actual position and velocity of the satellite at a
specific point in time (the orbit epoch). This information is enough to enable the MCC (or LUT)
system to compute the position of the satellite at any time in the past or future (subject to the
accuracy limitations of the computer system).

A-34

A.7.2.2
NORAD Two-Line Elements
The Two-Line Elements (TLE) are a format for the orbital data of a satellite in orbit around the
Earth. It was developed in support of the simplified perturbations models, a set of mathematical
models (SGP, SGP4, SDP4, SGP8 and SDP8) that are used to calculate the orbital state vectors of
satellites and space debris relative to the Earth-centred inertial coordinate system. [The acronyms
represent the Simplified General Perturbations (SGP) model for near earth objects and Simplified
Deep Space Perturbations (SDP) for more distant objects.] The TLE format is used by the North
American Aerospace Defence Command (NORAD) to track objects in Earth orbit.
Because many of the values that are included in the TLE format do not change over time, they are
easier to use in orbit computation models than the position and velocity vectors. It is possible to
convert between the different sets of orbital elements, but the use of the TLE data simplifies the
processing that has to be done in the computer systems.
The TLE format has come to be accepted as a de facto standard for the distribution of the orbital
elements of an object in orbit around the Earth. The formatting and use of the TLE orbital elements
in the SIT messages from an MCC are described in more detail in section B.6.1.2 of this Handbook.
A.7.2.3
Orbit Reference Coordinate System
When MEOLUTs are linked in a network, they exchange time and frequency readings in a set of
text files that are encoded in the Extensible Mark-up Language (XML). Although these files are
not in the SIT message formats that are used between MCCs, they are also specified in the SID
(document C/S A.002), and they also make use of the data in the Message Formats that are defined
in the SID.
In order to ensure that accuracy of the data that is exchanged between MEOLUTs, these XML files
may also need to include the related satellite orbit data. The orbit data, as position and velocity
vectors, may be in either of two coordinate systems:
• an Earth-Centred Earth-Fixed coordinate system that rotates with the Earth,
• an Earth-Centred Inertial coordinate system that does not rotate with the Earth.
Message Field 87 is included in the XML file to specify which coordinate system is used for the
orbit data in that file.
A.7.3
System Calibration
To enable the LUT and MCC systems to compute the beacon location estimates, and to achieve
the accuracy that is desired of the system, certain items of calibration data are also distributed
through the MCC network, as described in the following sections.
A.7.3.1
SARP Calibration
As explained in section 6.10.4 of this Handbook, the LEOLUTs require calibration data to interpret
the time and frequency measurements that are received from the Search and Rescue Processor

A-35

(SARP) instruments on the LEOSAR Sarsat spacecraft. Every week, the French MCC distributes
this SARP calibration data to all MCCs.
When an MCC receives a SARP Calibration message, it should validate the calibration data and
then forward it to its associated LEOLUTs. Each LEOLUT may then use this data to validate its
own calibration, and to update it as necessary.
A.7.3.2
SARR Calibration
As explained in section 6.10.5 of this Handbook, the LEOLUTs should also receive calibration
data so that they can accurately report the frequency measurements that are received from the
Search and Rescue Processor (SARP) instruments on the LEOSAR Sarsat spacecraft. Every
month, the Canadian MCC distributes this SARR calibration data to all MCCs.
When an MCC receives a SARR Calibration message, it should validate the calibration data and
then forward it to its associated LEOLUTs. Each LEOLUT may then use this data to validate its
own calibration, and to update it as necessary.
A.7.4
Spacecraft Instrument Control Messages
The spacecraft instrument control messages are specialized messages that are used by the Space
Segment Providers for the control of the Search and Rescue instruments on the satellites of the
Cospas-Sarsat Space Segment. The details of the message formats and the message fields that they
contain are described in section B.6.4 of this Handbook. These message formats are not used by
other MCCs.
A.7.5
System Status and Narrative Messages
The status and narrative messages are used to distribute information that may be of interest to the
Ground Segment Providers in the Cospas-Sarsat System.
These messages use the same control data message fields as the other SIT messages, as listed in
Table . However, the actual information in each message is in Message Field \#41, which is
essentially a free-format stream of text characters that can be read by the operator at the receiving
facility.
The message text is divided into a sequence of lines, each of which has fewer than 70 characters,
and which is terminated by an end-of-line sequence (carriage return – carriage return – line feed).
The only limitation on the contents of these messages is the length of the message:
• each message must contain no more than 25,000 characters.
• for a message that is to be transmitted over an AFTN communications network, the
message must not exceed 2100 characters in total, and the content of the SIT message
inserted into the AFTN message must not be more than 1800 characters.
In addition, the text sequence is terminated by the characters “QQQQ”; for obvious reasons, this
sequence may not appear anywhere else in the message.

A-36

A.7.5.1
System Status
The SIT 605 message is a system status message that is distributed to all MCCs. A SIT 605
message may be generated automatically by the MCC computer system in response to a predefined
circumstance, or it may be entered into the system by the MCC operator. Uniquely in these
messages, the destination facility code in MF \#5 is not used to identify the final destination to
which the message should be sent. Unlike other SIT messages, this message field is used to indicate
the immediate next destination.
The originating facility sends the message to its nodal MCC, from which it is then to be forwarded
to all nodal MCCs. Each nodal MCC modifies MF \#5 and distributes this message to all MCCs
within its Data Distribution Region (DDR). In this way, the status information is rapidly distributed
to every MCC in the network.
A.7.5.2
Narrative Messages
The SIT 915 message is a simple narrative message. It is generated, usually by operator entry, at
the source facility and it is sent (through the MCC data distribution network) to the destination
facility.
A.7.6
Beacon Registration Data
Every country that participates in the International Maritime Organization (IMO) or the
International Civil Aviation Organization (ICAO) is required, by the terms of their participation
in those organizations, to maintain a registry of all distress beacons that are identified with their
country code in the beacon message. The Cospas-Sarsat MCC that serves the area that includes
the country must have access to the national beacon registration database and must support
requests for the registration information from any other MCC.
This support includes the ability to respond to requests, from the responsible authorities, for
information about any beacon with a country code in the MCC Service Area. As each request is
received, the MCC must forward the request for information to the appropriate national beacon
registry and must return the information retrieved to the requesting authority.
For any country that does not maintain its own beacon registry for a particular type of distress
beacon, the Cospas-Sarsat Programme maintains the International Beacon Registration Database
(IBRD), which will manage the registration records of the specified type of beacons for that
country. Access to the IBRD is available to all Cospas-Sarsat MCCs (and to all authorized SAR
authorities).
- END OF ANNEX A -

B-1

ANNEX B: DESCRIPTION OF SIT MESSAGES
One of the most important tasks of an MCC is to distribute the information that is used in the
Cospas-Sarsat System, especially the incident alert data that is generated when a message from a
Cospas-Sarsat distress beacon is received by the Ground Segment of the System. This information
is distributed to the appropriate destination, as described in Annex A of this Handbook, in one of
the message formats that are specified in the document C/S A.002, “Cospas-Sarsat Standard
Interface Description” (the SID). This Annex is intended to provide additional information about
the structure of these messages and about the meaning of some of the individual data items that
they may contain.
The following annexes to the SID contain the detailed specifications for the formats of the
messages that are used in the Cospas-Sarsat data distribution network:
•
ANNEX A
“Subject Indicator Types (SITs)”,
•
ANNEX B
“Message Field Description”,
•
ANNEX C
“Message Content by SIT”,
•
ANNEX D
“Useful Information for Standard Message Formats between MCC
and RCC”.
Some of the contents of these annexes to the SID is explained further in this Annex of this
Handbook.
The SID includes a special set of message formats, identified as SIT number 185, which is used to
send the incident alert data to a Search and Rescue Point of Contact (SPOC). Although these
formats are officially designated for transmission to a SPOC, the same formats are usually used to
send the incident alert information to the national Rescue Coordination Centres (RCCs) that are
associated with an MCC. The information that is contained in these SIT 185 messages is explained
further in document C/S G.007, “Handbook on Distress Alert Messages for Rescue Coordination
Centres (RCCs), Search and Rescue Points of Contact (SPOCs) and IMO Ship Security Competent
Authorities”. The explanation of the SIT 185 messages is not duplicated in this annex.
B.1
International Character Set
As per section 4.2 (“Character Set”) of document C/S A.002, “Cospas-Sarsat Mission Control
Centres Standard Interface Description”, and as listed in the tables in that section:
•
Table 4.1
“International Alphabet No.5 (IA5))”,
•
Table 4.2
“International Telegraph Alphabet No.2 (ITA2))”,
•
Table 4.3
“Equivalents for Translation between International Telegraph
Alphabet No.2 and International Alphabet No.5”,

B-2

The contents of every MCC message are limited to the characters that are included in both ITA2
and IA5; no other characters are accepted as valid in the text of a message that is generated and
transmitted by an MCC.
The octothorpe character (“\#”), which is used in some communications networks as a control
character, is not permitted in an MCC message.
Some characters that are required in MCC messages are not available in the permitted character
set; those characters are replaced by specific character sequences, as listed in Table . Note that
these restrictions apply to all messages, regardless of the communications network that is used.
Table B-1: Replacement Character Sequences
The characters listed in the first column of this table must be replaced by the indicated character
sequence in an MCC message.
Character
Description
Replacement Sequence
@
“At” sign
(AT)
%
Percent sign
PERCENT
\_
Underscore character
(UNDERSCORE)
B.2
Message Subject Indicator Types
Every message that is generated and transmitted by an MCC to another MCC is identified by a
Subject Indicator Type (SIT) code number, which defines the format of the message. All of the
valid SIT codes, and the associated formats, are described in the SID.
Most of the message formats that are defined in the SID are designed for automated processing,
so that they can be read and processed by the computer systems in an MCC. The major exception
to this rule is the SIT 185 messages that are sent to RCCs and SPOCs, which are less rigidly
constrained, and are designed for a human reader. As noted above, the contents of these messages
are described in C/S G.007. Because these messages are created from the data that is received by
an MCC in the other SIT formatted messages, there is much overlap in the contents of these
messages. The intent of this annex is not to reproduce the information from C/S G.007, but to
provide additional information about the meaning of some of the individual data items that may
be contained in all of the incident alert messages.
The SIT message numbers that are used to distribute the incident alert data between MCCs are
organized into blocks, according to the type of data that is in the message, as identified in Table 2,
Table 3, and Table .
Table B-2: Alert Messages by Beacon Generation
The only exception to the assignment of these blocks of numbers is the SIT185 message, which may
be used for an alert message from either an FGB or an SGB.

B-3

SIT
Message
Numbers
Description
100 - 199
Formats for First-Generation Beacon (FGB) incident alert messages
300 - 399
Formats for Second-Generation Beacon (SGB) incident alert messages
Table B-3: LEOSAR and GEOSAR Alert Messages
Note that, for those messages with the superscript on the location type (“Doppler1”), the message may
(or may not) also include an encoded location.
Note also that the LEOSAR system is not expected to support the Second-Generation Beacons; the
SGB formats that have “LEO/GEO” will only be supported by the GEOSAR system.
SIT Message
Numbers
Satellite
System
Description
Location Data
FGB
SGB

LEO/GEO
Interferer Alert
Doppler


LEO/GEO
Incident Alert
No Doppler


LEO/GEO
Conflict Alert
Encoded only


LEO/GEO
Position Confirmation Alert
Encoded only

LEO/GEO
Incident Alert
Doppler1

LEO
Conflict Alert
Doppler1

LEO
Position Confirmation Alert
Doppler1


LEO/GEO
Notification of Country of Registry (NOCR)
Encoded only

LEO/GEO
Notification of Country of Registry (NOCR)
Doppler1


LEO/GEO
Notification of Return Link Service Provider
Encoded only

LEO/GEO
Notification of Return Link Service Provider
Doppler1
Table B-4: MEOSAR Alert Messages
Note that, for those messages with the superscript on the location type (“DOA1”), the message may
(or may not) also include an encoded location.

B-4

SIT Message
Numbers
Satellite
System
Description
Location Data
FGB
SGB


MEO
Notification of Country of Registry (NOCR)
Encoded only


MEO
Notification of Country of Registry (NOCR)
DOA1


MEO
Notification of Return Link Service Provider
Encoded only


MEO
Notification of Return Link Service Provider
DOA1

MEO
Interferer Alert (DOA location)
DOA


MEO
Incident Alert
No DOA


MEO
Conflict Alert
Encoded only


MEO
Position Confirmation Alert
Encoded only


MEO
Incident Alert
DOA1


MEO
Conflict Alert
DOA1


MEO
Position Confirmation Alert
DOA1
B.3
Message Fields
Each SIT message format is defined as a series of Message Fields. Each message field is identified
by a Message Field Number (MF\#) and is described in the SID. In a SIT message, the message
fields are normally (but not always) separated by either a slash (“/”) or an end-of-line sequence
(carriage return, carriage return, line feed: “cr-cr-lf”).
The message fields are described in detail in Annex B of the SID. That annex contains:
• Table B.1 (“Message Field Description”), in which the format of each message field is
specified, and
• Appendix B.1 to Annex B (“Message Field Definition”), in which the meaning and use of
each message field is defined and explained.
The next section explains how the message field descriptions are specified in Table B.1 of the SID.
The following sections identify the Message Fields that are used for specific functions in the
messages that are generated and transmitted by an MCC.
The SID also contains an Annex C (“Message Content by SIT”), which identifies the message
fields (by MF\#) that are contained in each of the SIT messages (by SIT number). This Annex C
also contains a collection of sample messages of various SIT numbers.
Unless the specifications in the SID leave room for ambiguity, the individual message fields are
listed, but not further described, in this Annex to the Handbook.

B-5

B.3.1
Message Field Identification
Each message field is identified by a message field number (MF\#). The MF \#is used in the SID to
specify every reference to that message field. Specifically, the descriptions of the message fields
in Table B.1 (“Message Field Description”) of the SID and the definitions of the message fields in
Appendix B.1 to Annex B (“Message Field Definition”) are both listed in the sequence of message
field numbers.
A message field number is normally a two-digit number (from 01 to 99). However, there are
several message fields (especially – but not only – those that are used in the SIT 185 message) that
have many variants; each of these variants is identified by a letter that is placed after the two-digit
number.
B.3.2
Message Field Descriptions
Each of the message field descriptions in Table B.1 of the SID contains four entries:
• The message field number (MF\#),
• The name of the field,
• A brief description of the contents of the field,
• The character text: a template of the character sequence that may be used in the field.
The meaning and use of each of these entries is explained in sections 2.1 to 2.4, respectively, of
Annex B of the SID. These entries for a set of four columns in the table.
The meanings of the first two columns are relatively clear.
The description of each message field explains the information that the field contains, including:
• The meaning of the data,
• The range of values that may be placed into the field,
• The default values to be used when there is no proper value available for the required data.
The template in the fourth column (character text) may indicate any of:
• the exact text to be placed in the field
-
represented as an upper-case letter character,
• any valid character
-
represented as the letter “a”,
-
see section B.1 of this handbook
• any valid hexadecimal character
-
represented as the letter “h”,

B-6

-
must be:
▪
a digit (0 to 9) or,
▪
an upper-case letter (A to F, representing 10 to 15).
• a sign symbol
-
represented as the letter “s”
-
must be the character “+” (plus sign) or the character “-” (minus sign)
• any decimal digit
-
represented as the letter “n”,
-
must be a digit (0 to 9).
• a blank space character
-
represented as the letter “b”,
-
must be the blank space character (“ ”).
Every message field is described in an entry in the Table B.1 of the SID.
B.4
Lists of Message Fields
The subsections of this section of this annex list and explain the message fields that are specified
in the SID. Where the explanation of the meaning and format of the message field in Table B-1
(“Message Field Description”) or in Appendix B.1 to Annex B (“Message Field Definition”) of
the SID are sufficient, no further explanation is provided here. However, in cases where the
specifications do not include enough information, additional explanation of the message field is
provided in the subsections below.
B.4.1
Control Fields
Every SIT message includes some of the control fields that are listed in Table .
Table B-5: Message Control Fields
The control message fields are used to indicate the beginning and end of each SIT message or of a
complete message. A spare data field is a field that has been reserved but is not currently being used
in any SIT message.

B-7

Message Field Number
Name

Message Number

Reporting Facility

Message Transmit Time

SIT

Destination

End of SIT

End of Message

End of Message (SIT 185)

Spare Data
The message number in MF \#1 contains two items:
• The first item is the sequence number of this message. This number is unique and sequential
for each destination. In the SID, Appendix B.3 to Annex B (“Suggested Algorithm for
Message Sequence Tracking”) describes an algorithm that can be used to identify any
messages that are missed, by tracking the sequence numbers of messages as they are
received at an MCC.
• The second part of the field is usually 00000; however, if this is a re-transmission of the
message, the second part of the field is the message number of the original message.
The reporting facility in MF \#2 identifies the system that sent this message to this MCC; it may be
either of:
• An MCC identifier,
• A LUT identifier.
The SID simply refers to the Cospas-Sarsat website, which has lists of the MCC numbers and the
LUT numbers.
An MCC identifier or a LUT identifier is a four-digit number built from the (3-digit) country code
of the Ground Segment Provider, with a single digit to identify the specific system:
• The MCC is identified by a zero (“0”) as the final character.
• Each LUT is identified by a single digit from 1 to 9, that identifies the LUT within the
country.
To find the identifier for a specific reporting facility:
The MCCs are listed under the <CONTACT LISTS> tab: <“PLEASE SELECT A CONTACT TYPE -” >
then <“MISSION CONTROL CENTERS”>. Scroll down to the MCC of interest, and then click on
<“DETAILS”>. The MCC identifier is listed after “MCC Code”.

B-8

• The LEOLUTs and GEOLUTs are listed under the <“SYSTEM”> tab: under “Detailed
LEOSAR/GEOSAR System Description”, select <“LIST OF LEOLUTS/GEOLUTS”>. In
the list, the LUT identifier is listed in the column “LUT Code”.
•  The MEOLUTs are listed under the <“SYSTEM”> tab: under “MEOLUT Configuration”.
The destination of a message may be either an MCC identifier or a LUT identifier (see above).
The SIT 185 message may be sent to other destinations; refer to C/S G.007 for more information
about the SIT 185 message.
B.4.2
Beacon Identification and Beacon Message
Each incident alert message contains one or more of the data fields listed in Table , which include
the beacon identification and the actual beacon message data (in hexadecimal format).
Table B-6: Beacon Identification and Message Fields
These message fields contain the beacon message data or the identification data fields that are
contained in the message that is transmitted by the distress beacon.
Message Field Number
Name
Size (hex digits)

Beacon ID


FGB 406 Message


FGB Full 406 Message


SGB Data


23-Hex Beacon ID


Beacon Data Field
Up to 64 per line
The details of the beacon messages and the beacon identifier formats are available in the Beacon
Specifications (documents C/S T.001, C/S T.015, and C/S T.018).
B.4.3
Solution Data
Each incident alert message may contain one or more of the solution data fields listed in Table .
Most of the message fields that are listed in this table are explained elsewhere in this Handbook;
the entries in the column “Reference” point to these explanations. The reference entry is “SID” if
there is no explanation in this Handbook to supplement the information in the SID.
Table B-7: Solution Data Message Fields
These message fields contain the solution data generated by the LEOSAR Doppler or MEOSAR DOA
processing that generates the independent location data for the beacon alert. These data items are
used in the Cospas-Sarsat incident alert data messages. The table does not include the message fields
that are designated for the SIT 185 messages.

B-9

Data Item
MF\#
System
Reference
Spacecraft ID

All
B.4.3.1
Orbit Number

All
B.4.3.2
Number of Alerts with Doppler/DOA positions

All
SID
Number of Alerts without Doppler/DOA positions

All
SID
Source ID

All
B.4.3.2
Local or Global Flag and Frequency Band

LEOSAR
B.4.3.4
Solution Frequency: Bias, BSDev, & Drift

LEOSAR,
GEOSAR
B.4.3.5
TCA (Time of Closest Approach) or
Time of Transmission (first or last burst)

All
B.4.3.6
Window Factor

LEOSAR
C.1.6
Number of Iterations

LEOSAR,
GEOSAR
C.1.1.1
CTA (Cross-Track Angle of Doppler solution)

LEOSAR
C.1.4
Secondary Source ID

LEOSAR &
GEOSAR
B.4.3.2
Number of Sidebands

LEOSAR
B.5.12.1
Sweep Period and Standard Deviation

LEOSAR
B.5.12.2
Number of Points or Bursts

All
B.4.3.7
Beacon Identifier
22, 92
All
B.4.2
Beacon Message
23, 77
(FGB)

(SGB)
All
B.4.2
DDR/Service Area and Position Status Flag

All
SID
Latitude

All
A.4.2.1
Longitude

All
A.4.2.1
Error Ellipse

LEOSAR
C.5.1
Probability

LEOSAR
C.1.2.1
Next Time of Visibility

LEOSAR
C.1.8
Confidence Factor (CF)

All
C.5.3
Data Residual

LEOSAR
SID
Antenna ID

MEOSAR
SID
C/N0

MEOSAR
SID
Bit Rate

MEOSAR
SID

B-10

Data Item
MF\#
System
Reference
DOA Quality Factor

MEOSAR
C.2.5
Average Carrier to Noise Ratio

MEOSAR
SID
Networked Antennas

MEOSAR
C.2.4.1
Antennas

MEOSAR
SID
Altitude

MEOSAR
A.4.2.1
Satellite IDs

MEOSAR
SID
Quality Indicator

MEOSAR
C.2.5
Number of Packets

MEOSAR
SID
Expected Horizontal Error

MEOSAR
C.2.5
MEOSAR Antenna IDs

MEOSAR
SID
B.4.3.1
Spacecraft Identification
A spacecraft Identification Code in MF \#6 is a three-digit decimal number that is assigned to each
of the spacecraft of the Cospas-Sarsat Space Segment. The spacecraft Identification Codes are
divided into blocks, as listed in the entry for MF \#6 in Table B.1 of the SID. These blocks of
numbers are also listed, with some additional information about the spacecraft, in Table  of this
Handbook.
Table B-8: Spacecraft Identification Codes
The LEOSAR and GEOSAR satellites have been numbered in sequence, as they were launched and
commissioned. For the MEOSAR satellites, the sequence number for an individual spacecraft within
each given range corresponds to the Pseudo-Random Noise number for that spacecraft.
Space Segment
Constellation
Numbers
Space Segment Operator
LEOSAR
Sarsat
001 - 099
Platform provided by USA
SARR provided by Canada
SARP provided by France
LEOSAR
Cospas
101 - 199
Russian Federation
GEOSAR
GOES
201 - 220
USA
GEOSAR
Electro-L &
Louch-5
221 - 240
Russian Federation
GEOSAR
INSAT
241 - 260
India
GEOSAR
MSG
261 - 280
European Commission
MEOSAR
SAR/GPS
300 - 399
Platform provided by USA
SARR provided by Canada
MEOSAR
SAR/Galileo
400 - 499
European Commission
MEOSAR
SAR/Glonass
500 - 599
Russian Federation

B-11

B.4.3.2
Orbit Number
The orbit number is the sequence number that counts the number of times that the satellite has
gone around the world. It starts at one and increments by one each time the satellite completes an
orbit (by crossing the equator in a northward direction).
The orbit number is limited to five decimal digits. If the number exceeds 99,999, then only the last
five digits of the actual orbit number are used. For example, after the satellite has completed one
hundred thousand revolutions around the Earth (and is on its 100,001st orbit), the orbit number is
provided as “00001”.
B.4.3.3
Source Identifier
The Source Identifier in MF \#11 is the identifier of the LUT that produced this alert:
• For a LEOSAR solution, it is the LEOLUT identifier.
• For a MEOSAR solution, it is the MEOLUT identifier.
For a solution that was produced by the LEOSAR combined LEO-GEO processing, there is also a
Secondary Source Identifier, MF \#18, which is the identifier of the GEOLUT that contributed data
for the solution.
Each of these Source Identifier codes is a LUT identifier, as described in section B.4.1 of this
Handbook.
B.4.3.4
Frequency Band
MF \#12 contains two separate items:
• The Local (“+” sign) or Global (“-” sign) flag indicates whether this alert is based on data
collected by the LUT in Local mode or in Global mode. For the LEOSAR system, the
values may be either “+” or “-”, as appropriate for the A-solution in the message. For the
MEOSAR and GEOSAR systems, the alert is always based on Local mode (“+”) data.
• The frequency band code is a one-digit decimal number that may be any of the values listed
in the in the entry for MF \#12 in Table B.1 of the SID. For a 406 MHz interferer solution,
the Frequency Band should be set to “+4”.
The frequency band values 1, 2, and 3 were originally assigned for 121.5 MHz and 243.0 MHz
solutions. Since the termination of processing of those bands, these values are no longer used.
B.4.3.5
Solution Frequency
The solution frequency data in MF \#13 consists of three separate sub-fields, separated by blank
spaces:
• The frequency bias is the offset, expressed in Hertz (Hz), of the frequency that has been
computed by the LUT for this beacon as a part of its solution processing.

B-12

• The bias standard deviation is the standard deviation (in Hz) of the offset of the frequency
measurements from the theoretical curve that was used in the solution processing to
determine the beacon location.
• The drift is the estimated rate of change of the beacon frequency over time (in Hz/minute)
during the period of the data that was used to determine the solution.
For all of these fields, the default value is used if no data is available or if the value of the parameter
is outside the permitted range.
B.4.3.6
Time
The time in MF \#14 is:
• For a LEOSAR solution, the Time of Closest Approach of the satellite to the beacon, as
described in section C.1.1.1 of this Handbook.
• For a MEOSAR solution, the time associated with this solution, computed as the average
of all the time of arrival measurements.
• For a GEOSAR solution, the time of the first beacon message processed for this alert.
The times of the first and last burst received for a MEOSAR DOA solution are provided separately
(as MF \#14a and MF \#14b, respectively).
B.4.3.7
Number of Points or Bursts
The number of points that are used to generate a solution in a LUT is reported differently for each
type of LUT:
•
LEOLUT
This is the number of unique time-frequency pairs that are used to
compute the Doppler A-solution.
For combined LEO-GEO processing, only the number of LEOSAR
points are included in this count.
•
MEOLUT
This is the number of different beacon transmissions (bursts) that
were used to generate a multi-burst DOA solution.
•
GEOLUT
Until the message is confirmed, this is always reported as 1.
After confirmation, this is the number of independent integrations
that produced the reported beacon message.
In each case, the number is reported in MF \#21.
B.4.4
Solution Quality Data
Most of the incident alert messages will contain one or more of the solution quality data fields,
which are listed in Table  and identified explicitly in Table . The specific fields that are used will
depend on the nature of the solution that is reported in the message, as indicated in Table 7.

B-13

Table B-9: Solution Quality Data Message Fields
These message fields provide information about the quality or accuracy of the independent location
data that is generated by the LUT processing.
Message Field
Number
Name

Solution Frequency: Bias, BSDev, & Drift

Window Factor

Number of iterations

Error Ellipse

Probability

Confidence Factor

Data Residuals, StdDev, & Trend

Quality Indicator

Expected Horizontal Error
B.4.5
Message Fields for SIT 185 Messages
The message data fields, MF \#45 to MF \#62, are defined for use in the human-readable SIT 185
incident alert messages. These SIT 185 messages, and the contents of the message data fields that
are used in them, are described in more detail in document C/S G.007, “Handbook on Distress
Alert Messages for Rescue Coordination Centres (RCCs), Search and Rescue Points of Contact
(SPOCs) and IMO Ship Security Competent Authorities”. They are not explained further in this
MCC Handbook.
B.5
Incident Alert Messages
Most of the message and beacon identification data is clearly defined in the SID (document C/S
A.002) or in the beacon specification document (document C/S T.001, C/S T.015, or C/S T.018,
as appropriate). However, the beacon location data, which may be generated in the beacon itself
or may be computed as an independent location by a Cospas-Sarsat Local User Terminal (LUT),
may require further explanation, as provided in the following sections of this Handbook.
In all cases, the position estimate that is generated by the Cospas-Sarsat System is only an estimate.
In general, the solution data provided by the Cospas-Sarsat LUTs (or by the data encoded in the
beacon message) is accurate. However, it is based on measured values which are all subject to the
possibility of error, and there is, therefore, always the possibility that the solution is not accurate.
Each of the different solution processing algorithms that are used by the Cospas-Sarsat LUTs
generates an estimate of the accuracy of the solution that it produces; these accuracy estimates are
explained in sections C.5 and C.6 of this Handbook.

B-14

As noted in the following sections, the format of the alert messages that are generated in each
situation depends on the type of beacon that is detected:
• The formats for first-generation beacon (FGB) alerts are SIT numbers between 100 and
199.
• The formats for second-generation beacon (SGB) alerts are SIT numbers between 300 and
399.
The only exception is the SIT 185 message format, which is used for both FGB and SGB alerts.
B.5.1
Unlocated Alerts
An unlocated alert is an alert that does not include any location data for the beacon. This may be
an alert from the GEOSAR system, which does not produce an independent location estimate, or
it may be from the LEOSAR or the MEOSAR system, when the LUT did not receive enough data
from the beacon to generate an independent location estimate.
An unlocated alert is distributed in the SIT 121 (FGB) or SIT 321 (SGB) message format. The
message fields that are contained in these messages are listed in Table 5, Table 6, and Table 7 in
section B.4 of this Handbook.
B.5.2
Encoded Location Alert
An encoded location alert is generated for a beacon that can determine its own position and encode
the location data in the transmitted beacon message. If the encoded location data is received
successfully by the LUT, then that data is available in the incident alert message that is generated
by the MCC.
The encoded location data is not formatted into the SIT message in a separate message field; it is
contained in the beacon message in one of the message fields listed in Table 6 of this Handbook.
An encoded location alert is distributed in any of the SIT message formats listed in Table  in
section B.2 of this Handbook. The message fields that are contained in these messages are listed
in Table 5, Table 6, and Table  in section B.4 of this Handbook.
B.5.3
Independent Location Alert
The LEOLUTs and MEOLUTs are both capable of computing estimates of the locations of the
beacons from which they receive signals. These are called independent location estimates; they
are independent of the location data that is received in the beacon message.
The independent location data is distributed in many of the different SIT message formats that are
listed in Table  and Table 4 in section B.2 of this Handbook.

B-15

B.5.3.1
Doppler Location Alert
The Doppler solution processing that is performed by the LEOLUTs normally generates two
distinct position estimates: one that is the correct location, and another that is the image of that
location, reflected in the plane of the satellite orbit. The LEOLUT also generates a value for the
probability that each of these estimates is the correct location. However, to resolve the ambiguity
between these locations and to determine which is correct, the MCC usually must compare the
location estimates from at least two independent sources and find a match that confirms one
position.
Based on the known satellite orbit information available to the MCC, the MCC can also determine
when the next satellite pass over each estimated position is expected to happen. With this
information, the MCC can include, in the incident alert message, the Time of Next Visibility of
the estimated location; this information may assist the RCC to determine whether or not to begin
a search and rescue operation immediately, or to wait until they have confirmation of one of the
estimated beacon positions.
When the beacon is first detected, and before the ambiguity can be resolved, the MCC sends a
Doppler solution message that contains both position estimates (and the estimated probability for
the A position). This provides the RCC with the information that the beacon has been activated.
Using the contact information in the beacon register, the RCC may be able to determine if there is
a true distress incident or if this is a false alarm. They may also receive enough information to
immediately resolve the position ambiguity, and to initiate the search and rescue operations.
Independent sources of location data may be any of:
• two Doppler position estimates based on different satellite passes in significantly different
orbital planes,
• a LEOSAR Doppler position estimate and a MEOSAR DOA position estimate,
• a LEOSAR Doppler position estimate and the position from the location data that is
encoded in the beacon message,
• a LEOSAR Doppler position estimate and a position estimate received from any other
independent source (such as, for example, an overflying airplane).
While most of these location data estimates can be processed and the ambiguity resolved
automatically by the MCC computer system, the last situation can often be resolved only by
manual intervention by the MCC operator.
When a solution is confirmed by a match within a specified tolerance, a separate confirmation
message (in a distinct SIT message format) is sent out by the MCC. The data in this message is
used to inform the RCC when the ambiguity is resolved. Once the location has been confirmed,
all future alert messages will be based on this beacon position.
When a new solution is received with a position that matches (within a defined tolerance) the
confirmed position, then a new alert message will be transmitted, to confirm that the beacon is still

B-16

active. For a beacon that is moving (for example, drifting at sea), this also provides information
about the changing position of the beacon.
When the new position is significantly different from the confirmed position, then a position
conflict message is transmitted. This identifies the possibility that there may be some concern
about the identification of the confirmed location:
• The original position estimate may not be correct.
• The confirmation may have identified the image solution instead of the correct position
estimate. (While rare, this can happen.).
• The beacon may be moving too rapidly for a single position estimate to define its position
accurately over a period of time.
With this knowledge, the MCC or RCC personnel can review the known information about the
distress incident, and decide what action is appropriate for the continued search and rescue
operation.
B.5.3.2
Difference of Arrival Location Alert
For each Difference of Arrival (DOA) location, the MCC is provided with the value of an Expected
Horizontal Error (EHE) (MF \#89), which will be forwarded in the incident alert message to the
RCC or SPOC. This value is the radius of the circle centered on the DOA location that should
contain the true beacon location with a 95% probability. In other words, there is a 95% probability
that the location error, which is defined as the distance between the DOA location and the actual
beacon location, is lower than the EHE value.
The EHE is explained in more detail in section C.5.2 in ANNEX C of this Handbook.
B.5.4
Special Message Formats
There are a number of special message formats that are required to support the distribution of
incident alert data in special circumstances. These circumstances, and the message formats that are
used to distribute the alert data in each circumstance, are described in the following sections of
this annex.
Several of these circumstances require unique message formats for the alerts. Table 10 identifies
the various circumstances when such messages may be required and lists the SIT message numbers
that are used in each case, as appropriate depending on the circumstances.
Table B-10: Special Alert Message Formats
The SIT message formats listed in this table may be used to transmit a confirmed alert message.
Subsystem
Beacon
Description
Confirmed
Alert
Conflict
Alert
NOCR
RLS
LEOSAR
FGB
Encoded
position only


B-17

Subsystem
Beacon
Description
Confirmed
Alert
Conflict
Alert
NOCR
RLS
LEOSAR
FGB
Doppler position


MEOSAR
FGB
Encoded
position only


MEOSAR
FGB
DOA position


GEOSAR
SGB
Encoded
position only


MEOSAR
SGB
Encoded
position only


MEOSAR
SGB
DOA position


B.5.5
Unconfirmed Location Alert
Although an alert message is distributed immediately when there is information available, the
MCC goes through a process of checking subsequent messages that relate to the same beacon to
confirm the detection and location of the beacon. This process is described in section A.4.3 of this
Handbook.
The alert message that is distributed before the incident has been confirmed is called an
unconfirmed location alert. This alert contains all of the information that is available for this
incident alert; however, the SIT number identifies it as an unconfirmed alert.
Unconfirmed alert messages may be sent in most of the SIT formats that are listed in Table  and
Table  in section B.2 of this Handbook.
B.5.6
Confirmed Location Alert
After the alert confirmation process, as described in section A.4.3 of this Handbook, has been
completed (and the beacon solution has been confirmed), a new alert for the same beacon will be
distributed as a confirmed alert.
A confirmed alert message is sent in one of the SIT message formats listed in the column
“Confirmed Alert” in Table , above.
B.5.7
Conflict Solution Alert
Each new alert is compared to the previous alerts for the same beacon in the alert confirmation
process, as described in section A.4.3 of this Handbook:
• Before the alert has been confirmed, if the new solution does not match any previous
solution, then the new solution is flagged as a conflict solution, and an alert is sent to inform
the recipients of this.

B-18

• After the alert has been confirmed, if the new solution does not match the confirmed
location, then the new solution is flagged as a conflict solution, and an alert is sent to inform
the recipients of this.
In each such case, the conflict alert is sent in one of the SIT message formats listed in the column
“Conflict Alert” in Table 10, above.
B.5.8
Notification of Country of Registry
A Notification of Country of Registry (NOCR) message is sent to the country where the beacon is
registered (based on the country code in the beacon message), as described in section A.4.7.5 of
this Handbook.
In each such case, the NOCR message is sent in one of the SIT message formats listed in the
column “NOCR” in Table , above.
B.5.9
Ship Security Alerting System Alert
An alert from a Ship Security Alerting System (SSAS) beacon is processed as described in section
A.4.7.1 of this Handbook.
The SSAS alerts are formatted in the same SIT message formats as any other alert would be
formatted in the same circumstances.
B.5.10 Aircraft Distress Tracking Alert
An alert from a Distress Tracking ELT(DT) beacon is processed as described in section A.4.7.3 of
this Handbook.
The ELT(DT) alerts are formatted in the same SIT message formats as any other alert would be
formatted in the same circumstances.
B.5.11 Return Link System Notification
A notification of Return Link System (RLS) message is sent to the MCC that is responsible for
liaison with the Space Segment Provider that operates the RLS satellite system, as described in
section A.4.7.2 of this Handbook. That MCC then forwards the alert to the Return Link Service
Provider (RLSP), who will issue the commands to the spacecraft as necessary to send the Type-1
Acknowledgement message on the satellite navigation signal to the beacon that initiated this alert.
In each such case, the RLS notification message is sent in one of the SIT message formats listed
in the column “RLS” in Table , above.
B.5.12 Interferer Alerts
The LEOSAR system can detect and locate strong interfering signals that are broadcast in the 406
MHz uplink frequency band. This is done by a processing that is very similar to the processing

B-19

that was done to detect and locate the 121.5 MHz and 243.0 MHz beacons, before that processing
was discontinued in 2009.
The interferer alert message contains a number of message fields that are not relevant to any of the
406 MHz distress beacon alerts, as listed in Table  and as described below.
An interferer is reported in a SIT 121 message. It is identified by a value of “+4” for the Frequency
Band (in MF \#12).
B.5.12.1
Number of Sidebands
A sideband is a band of frequencies, higher than or lower than the carrier frequency, that are the
result of the modulation process. When the interferer processing discovers a sideband to a signal
that it is processing, the frequency data is adjusted to match the frequency of the primary signal,
and the data is combined with the primary data to improve the quality of the solution.
The number of sidebands that are detected and processed is reported in MF \#19.
B.5.12.2
Sweep Period and Standard Deviation
The distress beacons that operate in the 121.5 MHz and 243.0 MHz frequency bands produce a
signal that sweeps across the band; this signal was originally intended to produce a characteristic
sound on an audio receiver, but it was used in the LEOLUTs to detect the signals from these
beacons.
The values that are reported for an interfering signal in MF \#20 are the default values.
B.6
System Information
The system data messages are listed in Table 4-4, with some indication of their contents. In
addition to the message fields that are listed in Table 4-4, these messages also contain many of the
control and identification message fields that are listed in Table  of this Handbook.
All of the message fields that are used in the SIT messages are specified in the SID (document
C/S A.002), in Table B-1 (“Message Field Description”) and in Appendix B.1 to Annex B
(“Message Field Definition”).
B.6.1
Orbital Elements
As explained in section 6.10, the orbital elements of a satellite are the data values that define the
path of the satellite around the Earth. They can be presented in a number of different formats:
• The Keplerian elements define the ellipse that is the path that the satellite follows around
the Earth.
• The Position and Velocity Vectors define the position and velocity of the satellite at a
specified time.

B-20

• The Two-Line Elements (TLEs) are a format developed by the North American Aerospace
Defence Command (NORAD) to specify the elements in a format that is designed for use
with the simplified perturbations models for the propagation of the orbit.
Other formats are also available. At one time, Cospas-Sarsat used the Keplerian elements to
exchange the LEOSAR orbit data; however, this was superseded by the use of the Position and
Velocity Vectors. More recently, the TLEs have been the standard for use with the MEOSAR and
GEOSAR systems.
B.6.1.1
SIT 215 Message Format (Orbit Vectors)
The SIT 215 message format is used to send a routine update of the orbit vectors for a LEOSAR
satellite. The data in this message should be verified by the MCC. The MCC can decide whether
or not the new elements should be forwarded to the associated LEOLUTs.
For the Cospas-Sarsat System, the position and velocity vectors are specified in an Earth-fixed
coordinate space; that is, a coordinate system that rotates with the Earth. The details of the Message
Fields that are used to place these parameters in the messages are described in the SID.
A sample of a SIT 215 message is available in Annex C of the SID.
B.6.1.2
SIT 216 Message Format (Orbit Vectors)
The SIT 216 message format is used to send a new set of orbit vectors after the completion of a
LEOSAR satellite manoeuvre. The data in this message may be verified by the MCC. However,
because the orbit after a manoeuvre is new, this data should always be forwarded to the associated
LEOLUTs. If the data is not sent to a LEOLUT, there is a risk that future Doppler solutions from
that LEOLUT will not be correct.
For the Cospas-Sarsat System, the position and velocity vectors are specified in an Earth-fixed
coordinate space; that is, a coordinate system that rotates with the Earth. The details of the Message
Fields that are used to place these parameters in the messages are described in the SID.
The format of the SIT 216 message is the same as that of a SIT 215 message, which is available in
Annex C of the SID. The only difference is the value in the SIT number field (MF \#4).
B.6.1.3
SIT 217 Message Format (Two-Line Elements)
The SIT 217 message format is used to send a routine update of the TLE orbital elements for a
MEOSAR satellite. The data in this message should be verified by the MCC. The MCC can decide
whether or not the new elements should be forwarded to the associated MEOLUTs.
The details of the Message Fields that are used to place the two lines in the messages, and the
meanings of each of the fields on these two lines, are described in the entries for MF \#85 and MF
\#86 in Appendix B.1 to Annex B (“Message Field Definition”) of the SID.
A sample of a SIT 217 message is available in Annex C of the SID.

B-21

B.6.2
LEOSAR SARP Calibration
As explained in section 6.10.4, the calibration data for the Search and Rescue Processor (SARP)
instrument that is carried on each of the Sarsat LEOSAR satellites is computed by the French MCC
(FMCC) and distributed through the Cospas-Sarsat data distribution network to all MCCs.
Table  contains a list of the message fields that are used to transmit the SARP calibration data.
Note that the calibration time (in MF \#37) is the time of the most recent rollover of the SARP time
counter; that is, the last time the counter had a value of exactly 000000.
Table B-11: SARP Calibration Data Message Fields
This table lists the Message Fields that are used in the SARP Calibration Data messages.
Message Field Number
Name

Calibration Time

USO Frequency
(for SARP-1 or SARP-2)
38a
USO Frequency
(for SARP-3)
There are two different SIT message formats that are used to transmit the SARP calibration data:
• The SIT 415 message format (for the SARP-1 and SARP-2 instruments),
• The SIT 417 message format (for the SARP-3 instruments).
Because the USO in the SARP-3 instrument operates at a different frequency than the earlier
versions, the MF \#38a requires an extra digit to specify the USO frequency.
Samples of a SIT 415 message and a SIT 417 message are available in Annex C of the SID.
B.6.3
LEOSAR SARR Calibration
As explained in section 6.10.5, Canadian MCC (CMCC) regularly transmits the current value of
the SARR Calibration data, through the Cospas-Sarsat data distribution network, to all MCCs.
Table  contains a list of the message fields that are used to transmit the SARR calibration data.
Table B-12: SARR Calibration Data Message Fields
This table lists the Message Fields that are used in the SARR Calibration Data messages.

B-22

Message Field Number
Name

SARR Frequency Calibration Offset

SARR Frequency. Calibration Drift

Time of SARR Frequency Calibration Determination
The SARR calibration data is sent in a SIT 510 message; a sample of a SIT 510 message is
available in Annex C of the SID.
B.6.4
Satellite Command and Control Messages
The satellite command and control messages are used to transmit the information required to
maintain control of the spacecraft and to keep them working as planned. These are specialized
messages that are used by the Space Segment Providers for the control of the SARP instruments
on the spacecraft of the Cospas-Sarsat Space Segment.
The SIT message formats that are listed in Table  and Table  are used for the control of the Search
and Rescue Processor (SARP) instruments and the Search and Rescue Repeater (SARR)
instruments on the LEOSAR satellites, respectively.
Table B-13: SARP Control Message Formats
These are specialized messages that are used by the Space Segment Providers for the control of the
SARP instruments on the spacecraft of the Cospas-Sarsat Space Segment.
SIT
Name
Description

SARP Telemetry
SARP telemetry data from a Sarsat spacecraft

SARP Out of Limit
Warning message to indicate abnormal performance of the SARP

SARP Command
Command request for the SARP instrument

SARP Command
Verification
Verification of the execution (or non-execution) of a SARP command
as requested by a command message
Table B-14: SARR Control Message Formats
These are specialized messages that are used by the Space Segment Providers for the control of the
SARR instruments on the spacecraft of the Cospas-Sarsat Space Segment.
SIT
Name
Description

SARR Telemetry
SARR telemetry data from a Sarsat spacecraft

SARR Out of Limit
Warning message to indicate abnormal performance of the SARR

SARR Command
Command request for the SARR instrument

SARR Command
Verification
Verification of the execution (or non-execution) of a SARR
command as requested by a command message
These satellite command and control messages are not normally of interest to any other MCC.

B-23

B.6.5
System Status
A system status message is sent to carry information about a change in the status of some part of
the System to all Ground Segment Providers. A system status message may provide information
about:
• The failure of:
-
A System element,
-
A System function.
• The recovery of a System element or function after a failure.
• Any reconfiguration of a System component.
• A scheduled event or activity, such as:
-
System maintenance,
-
Integration of new System elements,
-
Testing of System elements.
• The commissioning of:
-
New equipment,
-
New capabilities of existing equipment.
In general, any information about the status of the Cospas-Sarsat System that may be of interest to
all Participants may be distributed in a system status message.
B.6.5.1
SIT 605
A system status message is sent in a SIT 605 format. The originating MCC sends the message to
its associated nodal MCC, which sends it, in turn, to all the other nodal MCCs. Each nodal MCC
than sends the message to all of the MCCs in its Data Distribution Region. In this way, all Cospas-
Sarsat Ground Segment Providers receive the message.
The information content of a SIT 605 message is contained in MF \#41, which is described in
section B.7.1 below.
A SIT 605 message may be generated by the automatic processing in an MCC computer, or it may
be entered manually by an MCC operator. In either case, it will be distributed to all MCCs.
The Cospas-Sarsat documents include a number of operational message templates, intended to
provide a standard format for some common messages, including several system status messages.
Some of these templates are discussed in section B.8 of this annex.

B-24

B.7
Narrative Messages
The data distribution system supports a number of narrative messages, which can be used to send
a variety of different information messages to other Ground Segment Providers.
The information content of many narrative messages is contained in MF \#41, which is described
in section B.7.1 below. Unlike most SIT messages, the narrative messages are intended for the
operator at the destination facility (MCC, LUT, RCC or other), and are not designed for automatic
processing.
The Cospas-Sarsat documents include a number of operational message templates, intended to
provide a standard format for some common messages, including several narrative messages.
Some of these templates are discussed in sections B.8 and B.9 of this annex.
There are several variations of narrative message that are used in the data distribution system. All
of them contain the standard control fields and many of them include the narrative text message
field. These different message formats are explained in the sections that follow.
Whatever the format, the narrative message will be sent, through the data distribution network, to
the specified destination.
B.7.1
Narrative Message Text
The information content of a system status message and of many narrative messages is contained
in MF \#41, which is a free-format sequence of narrative text. The text may be broken up into a
sequence of individual lines, separated by an end-of-line sequence (carriage return, carriage return,
line feed: “cr-cr-lf”). Any sequence of valid characters (see section B.1 of this Annex) may be
inserted into a narrative message, except for the termination sequence described below.
The information text in a narrative message is terminated by the termination sequence:
• Two carriage returns,
• One line feed,
• Four “Q” letter characters,
• Two carriage returns,
• One line feed.
In essence, this appears in the message as a new line that contains “QQQQ” and nothing else.
B.7.2
SIT 915 (Simple Narrative Message)
The SIT 915 message is a simple narrative message, which sends a block of free-format text to the
destination. The text of a SIT 915 message is usually typed by the MCC operator.
The information content of a SIT 915 narrative messages is contained in a narrative text message
field, as described in section B.7.1 of this annex.

B-25

B.7.3
SIT 925 (406 MHz Beacon Information with 15-Hex ID)
The SIT 925 message is used to provide the registration information for a distress beacon, using
the beacon identifier (15-character hexadecimal). The message contains the beacon identifier in
MF \#22, followed by a free format narrative text field (see section B.7.1 of this annex).
B.7.4
SIT 926 (406 MHz Beacon Information with 23-Hex ID)
The SIT 926 message is used to provide the registration information for a distress beacon, using
the beacon identifier (23-character hexadecimal). The message contains the beacon identifier in
MF \#92, followed by a free format narrative text field (see section B.7.1 of this annex).
B.7.5
SIT 927 (SGB Type Approval Information for MCCs)
The SIT 927 message is used to distribute information about the operational characteristics of a
second-generation beacon, as retrieved from the Type Approval Certificate (TAC) that was filed
when the beacon was approved for use with the Cospas-Sarsat System.
The SIT 927 message is generated by an MCC every time a new 406 MHz beacon design is type-
approved. Like a SIT 605 message, the SIT 927 message is distributed to all MCCs. The intent of
this message is to enable every MCC to build its own internal database that contains all of the
necessary information about the beacons, so that they will be able to retrieve that information when
it is required in an incident alert message in the future, without requiring access to the TAC
database that is operated by the Cospas-Sarsat Secretariat.
Table B-15: SGB Information from TAC
These message fields are used to transmit the information from the Type-Approval Certificate
database (built up from the contents of SIT 927 messages that are distributed as the beacons are type-
approved).
MF\#
Name
Description

C/S Type Approval
Certificate (TAC)
Number information
1. First TAC number reported
2. Number of consecutive TACs reported
3. Total number of TACs in database

Beacon Manufacturer
Name
SID

Beacon Model Name
SID

Beacon Data Field
Beacon characteristics (described and explained in the SID)
B.7.6
SIT 985 (SGB Type Approval Information for SPOCs and RCCs)
The SIT 985 message is used to distribute information about the operational characteristics of a
second-generation beacon, as retrieved from the Type Approval Certificate (TAC) that was filed
when the beacon was approved for use with the Cospas-Sarsat System.

B-26

The SIT 985 message is used to provide this information to the distress authorities who will be
dealing with an incident alert from the subject beacon. As an interim measure, it is also used to
send this information to an MCC that is not qualified as an SGB-capable MCC.
The SIT 985 message provides this information in the same message fields that are designated for
use in a SIT 185 message (MF \#61b and MF \#61c). The data from this message can be taken and
moved directly into the SIT 185 message to be sent to the distress authorities.
B.8
Operational Message Templates
As noted above and as listed in Table , the Cospas-Sarsat documents include a number of
operational message templates, intended to provide not only a standard format for some common
system status and narrative messages, but also to indicate the contents that would be appropriate
in specific circumstances.
Table B-16: Operational Message Templates
This table contains a list of many of the templates that are provided in the Cospas-Sarsat documents
for system status messages and narrative message that are commonly used in the System.
Document
Reference
Section Figure
Description
C/S A.001
4.3   4-16
Beacon Test Co-ordination Message
C/S A.001
5.2    5-1
Standard Message for Reporting Satellite Payload Status
(See also sample messages in the SID: C/S A.002 Annex C)
C/S A.001
5.2    5-2
Standard Message for Reporting Satellite Manoeuvres
C/S A.001
5.2    5-3
Standard Message for Reporting Reactivation of the SARP
Instrument
C/S A.001
5.2   5-4
Standard Message for Reporting a Spacecraft Anomaly
Some of these templates are discussed in the following parts of this section. Some additional
sample messages are also presented and discussed in these following sections.
In addition to the messages discussed here, Annex C of the SID (document C/S A.002) contains
samples of many other different message formats.
B.8.1
SIT 605 – MCC Backup
Figure B.1 contains a sample announcement from a nodal MCC when it takes over as the backup
for a non-nodal MCC in its Data Distribution Region (DDR). This message includes the
information that the other MCCs in the DDR should be aware of:
• The identification of the non-operational MCC (the Italian MCC – ITMCC),
• The identification of the MCC that is providing the backup service (the French MCC –
FMCC),
• The times of the failure and the backup,

B-27

• A request that all MCCs in the DDR acknowledge receipt of the message,
• The contact information of the MCC that is providing the backup service,
At any time when an MCC takes over as backup for another MCC, it should provide this
information to all MCCs.
FROM: FMCC
TO: ALL MCCS
SUBJECT: ITMCC BACKUP
1. ITMCC IS NOT OPERATIONAL FROM 0725 UTC DUE TO MAINTENANCE
2. THE FMCC HAS ASSUMED THE BACKUP AND DUTIES OF ITMCC AT 1200 UTC
3. MCCS ARE REQUESTED TO TRANSMIT ALL TRAFFIC FOR THE ITMCC TO FMCC
4. CENTRAL DDR MCCS ARE INVITED TO CONFIRM RECEIPT OF THIS MESSAGE BY
SENDING AN ACKNOWLEDGE MESSAGE TO THE FMCC AFTER THE CONFIGURATION
CHANGES ARE MADE
5. ITMCC WILL INFORM WHEN IT RESUMES THE NORMAL OPERATIONS.
6. FMCC COMMUNICATION ADDRESSES:
AFTN LFIAZSZX
FAX: +33 561 274 878
PHONE: +33 561 254 382
BEST REGARDS,
FMCC
Figure B.1: Sample SIT 605 Announcement of MCC Backup
This sample message shows the announcement of an MCC assuming the backup of a not operational
MCC that is not a nodal MCC.
Note that this example is for the backup of an MCC in the Central DDR (CDDR). Because of a
special arrangement in the CDDR, all MCCs within that DDR are configured to send alert
messages to any other MCC in the same DDR; item 4 in the message includes a reminder that
these MCCs will have to change their configuration to continue to support the network while the
ITMCC is backed up by the FMCC.
Figure B.2 and Figure B.3 contain announcements of the backup of a nodal MCC by another nodal
MCC.

B-28

FROM: AUMCC
TO: ALL MCCS
SUBJECT: AUMCC BACKUP OF USMCC
1. THE UMCC HAS REQUESTED THE AUMCC TO BACKUP THE USMCC AND UNDERTAKE THE
ROLE OF THE NODAL MCC FOR THE WESTERN DDR.
2. THE AUMCC HAS BEEN RECONFIGURED TO ACCEPT USMCC ALERT DATA FROM
WESTERN DDR MCCS AND NODAL MCCS AND HAS ASSUMED THE USMCC NODAL
RESPONSIBILITIES.
3. WESTERN DDR MCCS AND NODAL MCCS ARE REQUESTED TO SEND A SIT 915 TO
AUMCC WHEN THEY ARE RE-CONFIGURED TO SEND USMCC TRAFFIC TO AUMCC.
5. WESTERN DDR MCCS SHALL NOT TRANSMIT QMS DATA TO THE AUMCC DURING THE
BACKUP.
6. AUMCC CONTACT NUMBERS ARE LISTED ON COSPAS-SARSAT WEB SITE.
REGARDS
AUMCC
Figure B.2: Sample SIT 605 Announcement of MCC Backup
This sample message shows the announcement of an MCC assuming the backup of a not operational
nodal MCC.
Although the formats are slightly different, both of these messages include the information that all
other MCCs should be aware of:
• The identification of the non-operational MCC,
• The fact that it is a nodal MCC that is being backed up,
• The identification of the MCC that is providing the backup service,
• A request that all MCCs in the DDR of the failed nodal MCC acknowledge receipt of the
message,
• Information about how to contact the MCC that is providing the backup service.
At any time when an MCC takes over as backup for another nodal MCC, it should provide this
information to all MCCs.
The message from the AUMCC in Figure B.2 also includes a reminder that, during the period
while the backup is in effect, the MCCs in the DDR of the failed nodal MCC should not send the
usual QMS data to the backup MCC. Since this is also stated in section 3.7.1 of the DDP, it is
useful, but not essential information for this notification message.

B-29

FM FMCC COSPAS-SARSAT TOULOUSE
TO ALL MCCS
DUE TO A TECHNICAL PROBLEM, FMCC ASSUMES THE BACKUP AND DUTIES OF THE CMC
EASTERN DDR AND NODAL MCCS ARE REQUESTED TO TRANSMIT ALL TRAFFIC FOR THE
CMC TO FMCC.
FMCC SENDS DIRECTLY ALERT DATA WITHIN THE CMC SERVICE AREA TO APPROPRIATE
SPOCS.
WE REQUEST NODAL MCCS AND EASTERN DDRS MCC TO CONFIRM RECEIPT OF THIS
MESSAGE BY SENDING A MESSAGE TO THE BACKUP FMCC AFTER CONFIGURATION
CHANGES ARE MADE
FMCC COMMUNICATION ADDRESSES:
AFTN: LFIAZSZX
FAX: +33 561 274 878
PHONE: +33 561 254 382
BEST REGARDS,
FMCC OPERATIONS
Figure B.3: Sample SIT 605 Announcement of MCC Backup
This sample message shows the announcement of an MCC assuming the backup of a not operational
nodal MCC.
B.8.2
SIT 605 – MCC Resuming Operations after the Backup
The messages in Figure B.4 and Figure B.5 are examples of the message that is sent from an MCC
after it has returned to operation, to notify all MCCs when the backup is finished.
FROM: ITMCC
TO: ALL MCCS
SUBJECT: ITMCC HAS RESUMED NORMAL OPERATIONS
1. THE ITMCC HAS RESUMED NORMAL OPERATION AT 2000 UTC, 15 JAN 2020.
2. CENTRAL DDR MCCS ARE REQUESTED TO RE-CONFIGURE THEIR MCC ACCORDINGLY.
BEST REGARDS,
ITMCC
Figure B.4: Sample SIT 605 Announcement of MCC Resuming Operations
This sample message shows the announcement of a non-nodal MCC resuming operations after it has
been backed up.
The message from the ITMCC in Figure B.4 notifies all MCCs that the backup that was notified
in Figure B.1 has been completed, and that the ITMCC and FMCC have returned to normal
operations. This message again includes a reminder to the CDDR MCCs that they will have to
reconfigure their systems to restore their normal network configuration.

B-30

FROM: AUMCC
TO: ALL MCCS
SUBJECT: AUMCC RESTORED TO NORMAL OPERATIONS
1. THE AUMCC HAS RESUMED NORMAL SOUTH WEST PACIFIC DDR MCC NODAL
RESPONSIBILITIES AT 2000 UTC, 15 JAN 2020.
2. NODAL MCCS, SOUTH WEST PACIFIC DDR MCCS SHOULD RESUME COMMUNICATIONS
WITH THE AUMCC.
3. MCCS ARE REMINDED THAT MESSAGE NUMBER SEQUENCES MAY INITIALLY BE OUT
OF SEQUENCE.
4. AUMCC THANKS USMCC FOR COOPERATION DURING THIS BACKUP TEST.
REGARDS,
AUMCC
Figure B.5: Sample SIT 605 Announcement of MCC Resuming Operations
This sample message shows the announcement of a nodal MCC resuming operations after it has been
backed up.
The message from the Australian MCC (AUMCC) in Figure B.5 is not related to the notifications
of backup in the earlier sample messages; it is a statement that the AUMCC has returned to normal
operations after it was backed up. (This backup would have been announced in a separate SIT 605
message, not included here.)
This message also includes two reminders for the receiving MCCs:
• MCCs in the South West Pacific Data Distribution Region (SWPDDR), for which the
AUMCC is the nodal MCC, should return to their normal operations.
• The sequence of message numbers will have been interrupted by the backup and will return
to normal after the backup is concluded. As a result, MCCs may expect to detect message
sequence errors on the next message received from the AUMCC.
These reminders are not essential, but they may be useful to the receiving MCCs.
B.8.3
SIT 915 – Beacon Test Coordination
Figure 4-16 (“Beacon Test Co-ordination Message”) in section 4.3 (“Procedures for the Co-
Ordination of Beacon Tests”) of the DDP (document C/S A.001) includes a template for a SIT 915
message to announce the plans for a test of a Cospas-Sarsat 406 MHz beacon.
This template includes the headers and titles to identify the expected content of each line of the
message. The intent of this message is to provide other MCCs with all of the information that they
may need to understand the plans for this test, and to inform them of where they can go to get more
information about this test.
Figure B.7 is an example of a message, based on the template in Figure 4-16 of C/S A.001, that
could be sent to notify other MCCs about plans for a beacon test. It shows the kind of information
that should be included in this notification message to ensure that the other MCCs are aware of the
test and that they will be able to deal with the data that it produces.

B-31

FROM: ITMCC
TO: DESIGNATED MCCS
SUBJECT: 406 MHZ BEACON TEST
A. TEST OBJECTIVE: FUNCTIONAL ELT BEACON TEST
B. TEST DESCRIPTION: NIL
C. LOCATION OF TEST:
LAT  45 42 N  LONG 008 41 E - VERGIATE, ITALY
D. DATE,TIME AND DURATION OF TEST:
13 SEP 2019 FROM 0730 UTC TO 0830 UTC
E. BEACON 15 HEX ID CODE: 1EE87AA22A8FFBFF
F. SPECIAL DATA COLLECTION AND PROCESSING REQUIREMENTS: NONE
G. POINT OF CONTACT
NAME: OPERATOR ITMCC
LOCATION: ITMCC OPERATION ROOM
TELEPHONE NO: +39 080 5344033-53441571
AFTN NO: LIJCYFYX
FACSIMILE NO: +39 080 5342145
BEST REGARDS,
ITMCC
Figure B.6: Sample SIT 915 Notification of a Planned Beacon Test
This sample message shows a notification message that could be sent to notify other designated MCCs
about a planned beacon test.
B.8.4
SIT 915 – Cospas-Sarsat Alert Results
After a distress alert has been sent out by an MCC, it is recommended that the MCC should
determine the results of that alert. Although there is no requirement to distribute this information,
it can be sent to other MCCs in a SIT 915 narrative message from the operator of the MCC that
originally sent the alert to the SAR destination. This information can also be sent to the Cospas-
Sarsat Secretariat, who collect information on the use of the Cospas-Sarsat System and publish it
in the annual Review of Cospas-Sarsat Status and Operations, which is reviewed at the annual
meeting of the Cospas-Sarsat Joint Committee and which is also sent to ICAO and IMO.
The illustrations in this section show some examples of such alert result messages.

B-32

FM ITMCC
TO CDDR MCCS
ITMCC REF NO 17085
HEXACODE: ADCDEA59F24020D
REF 406 BEACON: A967C9/0, COUNTRY:366 USA
INFORMATION RECEIVED FROM IT-MRCC ROME
RESULT: FALSE ALERT
TYPE: B777
AIRCRAFT REG: N70GT
OPERATOR: COMMERCIAL
PLACE/POSITION: VERGIATE, ITALY (LILG)
REASON OF BEACON ACTIVATION: BEACON MISHANDLING
OTHER INFO: NIL
BEST REGARDS,
ITMCC
Figure B.7: Sample SIT 915 Notification of a False Alert
This sample message shows the notification that is sent after an alert is determined to have been a false alert.
Figure B.7 is a message that can be sent to inform other MCCs when a false alert has been reported.
It contains information about the beacon itself, as well as the reported reason for the activation of
the beacon that resulted in the false alert.
To assist MCC operators when identifying and reporting operational false alerts categorized under
the seven categories in document C/S A.003, section “Operational False Alerts” and its
Appendix A.1, Figure B.8 below provides an information graphic to visually depict operational
false alerts.
Figure B.8: Information Graphic on Sources of False Alerts

![Image 1 from page 205](/images/cospas-sarsat/G-series/G010/G010_page_205_img_1.png)

B-33

Figure B.9 below is a message that can be sent to inform other MCCs about a real distress incident
that has been reported. It contains information about the beacon itself, as well as information about
the results of the Search and Rescue operation triggered by this alert. (Because of the size of the
message, the figure has been divided into two parts in this Handbook.)
FM ITMCC
TO CDDR MCCS
REF 406 BEACON HEXACODE FROM MRCC ROME
QUOTE
A: VESSEL/CRAFT IDENTITY
NAME: ISVFG
TYPE: CESSNA 152
CALLSIGN: ISVFG
FLAG: ITALY
POSITION: 46 10.1 N 011 22.4 E - TRENTO, ITALY
B: BEACON TYPE
() EPIRB
(X) ELT
() ELT(DT)
() PLB
C: ALERT CLASSIFICATION
(X) DISTRESS ALERT
() FALSE ALARM
() UNDETERMINED (INCLUDING STOPPED BEFORE LOCATED)
D: CAUSE OF ACTIVATION
(X) CRASH
() BEACON MISHANDLING
() BEACON MALFUNCTION
() MOUNTING/AVIONICS INTERFACE FAILURE
() ENVIRONMENTAL CONDITIONS
() MAINTENANCE ACTIVATION
() VOLUNTARY ACTIVATION
() UNKNOWN
E: PERSON INVOLVED
NUMBER OF PERSON INVOLVED: 2
RESCUED: 2
INJURED: NIL
SAFE: 2
DEAD: NIL
MISSING: NIL
F: TYPE OF ALERT
() ONLY ALERT
(X) FIRST ALERT
() SUPPORTING DATA
() DATA NOT USED IN SAR
G: OTHER INFO:
PLEASURE AIRCRAFT CESSNA 152 CRASHED 5KM SOUTHEAST OF TRENTO, ITALY
DUE TO ENGINE FAILURE. TWO (2) POB WERE RESCUED SAFE AND WELL.
UNQUOTE
BEST REGARDS,
ITMCC
Figure B.9: Sample SIT 915 Notification of a Real Distress Incident
This sample shows a narrative message that is distributed with information about a real distress
incident that was reported by the Cospas-Sarsat System.

B-34

There is no specific information that is required in this message; the intent is to provide useful
information about the incident that resulted in the original alert, and the contribution of the Cospas-
Sarsat System in resolving the matter. Of course, the successful rescue of the persons on board the
aircraft is important to report.
B.8.5
Filtering Doppler Position
The procedures for the filtering of data are specified in sections 3.2.3.2 (“Filtering of Redundant
Data”) and 3.2.10 (“Filtering Old Alert Data”) of document C/S A.001, “Cospas-Sarsat Data
Distribution Plan”.
The examples in this section show the results of QMS testing by a nodal MCC. The messages that
are used are based on the templates that are contained in document C/S A.003, “Cospas-Sarsat
System Monitoring and Reporting”, and are listed in Table  of this Handbook.
When an anomaly is detected, the nodal MCC sends a narrative message, using the format of one
of the status warning messages from these templates as shown in Figure B.10, to the associated
MCC to notify them of the anomaly and to request that they suppress any data that may be
unreliable. At the same time, the associated MCC is expected to investigate and to correct any
problem that may have caused this anomaly.
/61939 00000/2270/20 139 1350 FTP
/915/2470
/SYSTEM ANOMALY NOTIFICATION MESSAGE
DATE: 1350 UTC, 18 MAY 2020
FROM: FMCC
TO: ITMCC
SUBJECT: LEOLUT LOCATION ACCURACY STATUS WARNING MESSAGE
1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE LEOLUT
AND SATELLITE COMBINATION IS NOT MEETING THE REQUISITE LOCATION ACCURACY
CRITERION AT 0000 UTC, 18 MAY 2020.
LEOLUT 2471 AND SATELLITE 12
THE PERFORMANCE FOR THIS COMBINATION IS R.5: 75.0 PERCENT, R.10: 100.0
PERCENT.
2. REQUEST A CHECK FOR THE CAUSE OF REDUCED LOCATION ACCURACY.
REGARDS
QQQQ
/LASSIT
/ENDMSG
Figure B.10: SIT 915 Location Accuracy Warning Message
This sample message is the notification to the associated MCC that the location accuracy for a
LEOLUT/LEOSAR combination is not compliant with the requirements in section 2.5.4.1 of
C/S A.003.

B-35

If the anomaly is not resolved and the 5-km accuracy ratio falls below 80%, a non-conformity
status message is then distributed to all MCCs to inform them of the issue and of any data
suppression that will result from it. The system status message, in Figure B.11, which shows the
results of QMS testing by a nodal MCC, is an example of such a message. In this case, the FMCC
has found that the Italian LEOLUT 2471 is not achieving the required location accuracy with data
from satellite S12, and the location data from this LUT / satellite combination is now being
suppressed. The SIT 605 message distributes this information to all MCCs.
In this case, the filtering does not require the complete suppression of the incident alert data. As
prescribed for the QMS processing, the alert data will continue to be distributed, but that
distribution will be based only on the beacon detection and on the information content of the
beacon message.
Following the notification of the SIT 605, the associated MCC, in accordance with procedures in
section 2.5.4.2 (b) (iii) of C/S A.003, sends a SIT 915 informing the nodal MCC that the alerts for
this LEOLUT / LEOSAR combination are being suppressed. Figure B.13 contains a sample of
such a message, sent from the ITMCC to the nodal FMCC informing that alert data from the
combination of LEOLUT 2471 and satellite S12 is being suppressed.
Continuing to follow the QMS requirements explained in section 4.6 of this Handbook, when the
problem has been resolved, the nodal MCC will distribute a new SIT 605 message to notify all
MCCs that the System solution accuracy of the LEOLUT/satellite combination has returned to
normal.

B-36

/61749 00000/2270/20 134 1350 FTP
/605/2470
/SYSTEM ANOMALY NOTIFICATION MESSAGE
DATE: 1350 UTC, 13 MAY 2020
FROM: FMCC
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 0000 UTC, 13 MAY 2020
LEOLUT 2471 AND SATELLITE 13
THE PERFORMANCE FOR THIS COMBINATION IS R.5: 50.0 PERCENT, R.20: 100.0
PERCENT.
2. THE CORRESPONDING CHANGES TO THE LOCATION ACCURACY AND AVAILABILITY
STATUS HAVE BEEN MADE TO THE COSPAS-SARSAT WEBSITE AND DOPPLER SOLUTION
DATA FOR THE LEOLUT AND SATELLITE COMBINATION IS BEING SUPPRESSED.
REGARDS
QQQQ
/LASSIT
/ENDMSG
Figure B.11: Sample SIT 605 Announcement of LEOSAR Location Accuracy Problem
This sample message is a notification that data for a described combination of LEOLUT and
LEOSAR satellite will be suppressed due to the results of the QMS testing by the nodal MCC. (See
section 2.5.4.2 of C/S A.003.)
/09919 00000/2470/20 134 1418
/915/2270
/FM ITMCC
TO FMCC
SUBJECT: LEOLUT LOCATION ACCURACY NON CONFORMITY STATUS MESSAGE.
IN ACCORDANCE WITH COSPAS SARSAT C/S A003 PARA 2.5.4.2 ITMCC HAS
FILTERED DOPPLER SOLUTION DATA FOR COMBINATION LEOLUT 2471 AND
SATELLITE S13.
BEST REGARDS
ITMCC
QQQQ
/LASSIT
/ENDMSG
Figure B.12: Sample SIT 915 Announcement of Doppler Location Filtering
This sample message is a notification that data for a described combination of LEOLUT and
LEOSAR satellite will be suppressed. (See section 2.5.4.2 of C/S A.003.)

B-37

The next sample, in Figure B.13, states that the accuracy produced by the identified combination
of the LEOLUT 2471 and the LEOSAR satellite S11 is now meeting the required standard, and
that the distribution of the solution data from this LUT / satellite combination has returned to
normal.
/61232 00000/2270/20 137 1350 FTP
/605/2470
/SYSTEM ANOMALY NOTIFICATION MESSAGE
DATE: 1350 UTC, 16 MAY 2020
FROM: FMCC
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
HAS RETURNED TO NORMAL AS AT 0000 UTC, 16 MAY 2020:
LEOLUT 2471 AND SATELLITE 13
2. THE CORRESPONDING CHANGE HAS BEEN MADE TO THE COSPAS-SARSAT WEBSITE
AND DOPPLER SOLUTION DATA FOR THE ABOVE LEOLUT AND SATELLITE COMBINATION
IS NO LONGER BEING SUPPRESSED.
REGARDS
QQQQ
/LASSIT
/ENDMSG
Figure B.13: Sample SIT 605 Announcement of LEOLUT/Satellite Conformity Status
This sample message shows the announcement from an MCC that the Doppler location accuracy
ratio for LEOLUT 2471 / Sarsat 11 combination has returned to the normal status. (See section
2.5.4.2(a)(i) of C/S A.003.)
/09922 00000/2470/20 137 1418 FTP
/915/2270
FM ITMCC
TO FMCC
SUBJECT: LEOLUT LOCATION ACCURACY CONFORMITY STATUS MESSAGE.
IN ACCORDANCE WITH COSPAS SARSAT C/S A003 PARA 2.5.4.3 ITMCC HAS
RESUMED THE DISTRIBUTION OF DOPPLER SOLUTION DATA FOR COMBINATION LEOLUT
2471 AND SATELLITE S13.
BEST REGARDS
ITMCC
QQQQ
/LASSIT
/ENDMSG
Figure B.14: Sample SIT 605 Announcement of the Resumed Distribution of Doppler Solutions
This sample message is a notification that data distribution for the described combination of
LEOLUT and LEOSAR satellite has been resumed. (See section 2.5.4.2(b)(ii) of C/S A.003.)

B-38

B.9
QMS Related Messages
The Cospas-Sarsat document C/S A.003 includes a number of templates for the messages that are
used in support of the Cospas-Sarsat Quality Management System (QMS). These templates, which
are listed in Table , are intended to provide not only a standard format for some common system
status and narrative messages, but also to indicate the contents that would be appropriate in specific
circumstances.
Table B-17: QMS Message Templates
This table contains a list of many of the templates that are provided in Annex D of document
C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”, for system status messages and
narrative message that are commonly used in the System.
Reference
Section
Description
1.1
LEOLUT Availability Status Warning Message
1.2
LEOLUT Availability Non-Conformity Status Message
1.3
LEOLUT Availability Conformity Status Message
2.1
GEOLUT Availability Status Warning Message
2.2
GEOLUT Availability Non-Conformity Status Message
2.3
GEOLUT Availability Conformity Status Message
3.1
LEOLUT Location Accuracy Status Warning Message
3.2
LEOLUT Location Accuracy Non-Conformity Status Message
3.3
LEOLUT Location Accuracy Conformity Status Message
4.1
MEOLUT Location Accuracy Non-Conformity Yellow Status Message
4.2
MEOLUT Location Accuracy Non-Conformity Red Status Message
4.3
MEOLUT Location Accuracy Conformity Status Message
4.4
MEOLUT Location Accuracy Non-Conformity Yellow Status (Change from Red
Status)
5.1
MEOLUT Location Probability Non-Conformity Yellow Status Message
5.2
MEOLUT Location Probability Non-Conformity Red Status Message
5.3
MEOLUT Location Probability Conformity Status Message
5.4
MEOLUT Location Probability Non-Conformity Yellow Status (Change from Red
Status)
6.1
MEOLUT Detection Probability Non-Conformity [Yellow or Red] Status Message
7.1
MEOLUT Local Antenna Availability Non-Conformity [Yellow or Red] Status
Message
8.1
MEOLUT Timeliness Non-Conformity [Yellow or Red] Status Message

B-39

Some of these templates are explained in section B.8.5 and in the following parts of this section.
In addition to the messages discussed here, Annex C (“Message Content by SIT”) and Annex D
(“Anomaly Notification Messages”) of the SID (document C/S A.002) contain samples of many
other different message formats.
If the data required to determine any of the parameters in the messages described below is not
available, then the value is reported as “n/i” [no information].
B.9.1
LEOLUT/LEOSAT Availability Status
As a part of the QMS, each nodal MCC monitors the availability of every combination of a
LEOLUT and a LEOSAR satellite that includes a LEOLUT in its DDR.
When the combination of an associated LEOLUT and LEOSAR satellite fails to meet the
availability criteria specified in section 2.5.2 (“LEOLUT Availability Assessment, Status
Reporting and Follow-Up Actions”) of C/S A.003, the nodal MCC in whose DDR the LUT is
located:
• Sets the availability status indicator for that LUT / satellite combination on the Cospas-
Sarsat website to yellow,
• Sends a SIT 915 message to warn the MCC with which the LUT is associated of this
availability problem,
• Continues to monitor the availability of this LUT / satellite combination.
Section 1.1 (“SIT 915 Warning Message” [LEOLUT Availability]) of Annex D of the document
C/S A.003 contains a template for the narrative message that is used to warn an MCC when the
combination of an associated LEOLUT and a LEOSAR satellite has failed to meet the availability
criteria.
This warning message is sent to request that the receiving MCC check its LEOLUT to determine
the cause of the reduced availability:
• If the LEOLUT is found to have a problem, then the system should be modified as
necessary to correct the problem. Once this has been done, the nodal MCC (and any other
MCCs that may have been affected) should be notified.
• If the investigation determines that there is no problem with the LUT, then the receiving
MCC should notify the nodal MCC and the Space Segment provider that is responsible for
the LEOSAR satellite involved, so that they can investigate and take action as appropriate.
If the combination continues to fail to meet the criteria for a three-day period, then the nodal MCC:
• Sets the availability status indicator for this LUT / satellite combination on the Cospas-
Sarsat website to red.
• Sends a SIT 605 message to notify all MCC of the non-conformance of the availability of
this LEOLUT / satellite combination.

B-40

• Continues to monitor the availability of that LUT / satellite combination.
The status message template in section 1.2 (“SIT 605 Status Message (Advising non-conformity)”
[LEOLUT Availability]) of Annex D of the document C/S A.003 is used to notify all MCCs when
the combination of the LEOLUT and LEOSAR satellite that are identified in the message has
failed to meet the availability criteria over a three-day period.
This non-conformance message is sent to inform all MCCs of the problem. No action is required
of the receiving MCCs; however, they should be aware that this situation may result in the LUT
not being able to provide alert data in its nominal coverage area:
• It may not be able to provide data to confirm an alert that has been detected and located by
another LUT/satellite combination.
• It may not produce solution data at the predicted next time of visibility for any beacon that
has been detected and located.
The receiving MCC may also wish to check the Cospas-Sarsat website to see if there is any other
related problem with the LUT or satellite involved, and to see when the data produced by this
LUT/satellite combination returns to the nominal availability.
When the availability returns to the normal range and has passed the appropriate criteria, the nodal
MCC:
• Sets the availability status indicator for this LUT / satellite combination on the Cospas-
Sarsat website to green.
• Sends a SIT 605 message to notify all MCC of the return to conformance of the availability
of this LEOLUT / satellite combination.
The nodal MCC notifies the other MCCs of the return to conformance of the availability of the
LEOLUT / Satellite combination in a SIT 605 message, following the template in section 1.3
(“SIT 605 Status Message (Advising return to normal operations)” [LEOLUT Availability]) of
Annex D of the document C/S A.003.
B.9.2
LEOLUT/LEOSAT Location Accuracy Status
As a part of the QMS, each nodal MCC monitors the location accuracy of the Doppler solutions
that are produced by every combination of a LEOLUT and a LEOSAR satellite that includes a
LEOLUT in its DDR.
When the combination of an associated LEOLUT and LEOSAR satellite fails to meet the location
accuracy criteria specified in section 2.5.4 (“LEOLUT Location Accuracy Assessment, Status
Reporting and Follow-Up Actions”) of C/S A.003, the nodal MCC in whose DDR the LUT is
located:
• Sets the location accuracy status indicator for this LUT / satellite combination on the
Cospas-Sarsat website to yellow.

B-41

• Sends a SIT 915 message to warn the MCC with which the LUT is associated of this
location accuracy problem.
• Continues to monitor the location accuracy of this LUT / satellite combination.
Section 3.1 (“SIT 915 Warning Message” [LEOSAR Accuracy]) of Annex D of the document C/S
A.003 contains a template for the narrative message that is used to warn an MCC when the
combination of an associated LEOLUT and a LEOSAR satellite has failed to meet the location
accuracy criteria.
This warning message is sent to request that the receiving MCC check its LEOLUT to determine
the cause of the reduced location accuracy:
• If the LUT is found to have a problem, then the system should be modified as necessary to
correct the problem. Once this has been done, the nodal MCC (and any other MCCs that
may have been affected) should be notified.
• If the investigation determines that there is no problem with the LUT, then the receiving
MCC should notify the nodal MCC and the Space Segment provider that is responsible for
the LEOSAR satellite involved, so that they can investigate further and take action as
appropriate.
If this LUT / satellite combination continues to fail to meet the criteria for a three-day period, then
the nodal MCC:
• Sets the location accuracy status indicator for this LUT / satellite combination on the
Cospas-Sarsat website to red.
• Sets the availability status indicator for this LUT / satellite combination on the Cospas-
Sarsat website to red.
• Sends a SIT 605 message to notify all MCC of the non-conformance of the location
accuracy of this LUT / satellite combination.
• Continues to process alert messages from this LUT / satellite combination following the
usual procedures for continuing QMS processing.
• Processes alert messages from this LUT / satellite combination for distribution to all other
MCCs based only on the contents of the 406 MHz message from the beacon, and not on
the independent location solution produced by the LUT.
• Continues to monitor the location accuracy of this LUT / satellite combination.
The status message template in section 3.2 (“SIT 605 Status Message (Advising non-conformity)”
[LEOSAR Accuracy]) of Annex D of the document C/S A.003 is used to notify all MCCs when
the combination of the LEOLUT and LEOSAR satellite that are identified in the message has
failed to meet the location accuracy criteria over a three-day period.
This non-conformance message is sent to inform all MCCs of the problem. Each receiving MCC
then processes alert messages from this LEOLUT / satellite combination based only on the
contents of the 406 MHz message from the beacon, and not on the independent location solution

B-42

produced by the LUT. During this period, they should be aware that this situation may result in
the LUT not being able to provide alert data in its nominal coverage area:
• It may not be able to provide data to confirm an alert that has been detected and located by
another LUT/satellite combination.
• It may not produce solution data at the predicted next time of visibility for any beacon that
has been detected and located.
Each receiving MCC may also wish to check the Cospas-Sarsat website to see if there is any other
related problem with the LUT or satellite involved, and to see when the independent location data
produced by this LUT/satellite combination returns to the nominal accuracy.
When the problem is resolved and the location accuracy returns to the normal range and has passed
the appropriate criteria, the nodal MCC:
• Sets the location accuracy status indicator for this LUT / satellite combination on the
Cospas-Sarsat website to green.
• Sets the availability status indicator for this LUT / satellite combination on the Cospas-
Sarsat website to green.
• Sends a SIT 605 message to notify all MCCs of the return to conformance of the location
accuracy of this LUT / satellite combination.
The nodal MCC notifies the other MCCs of the return to conformance of the location accuracy of
this LEOLUT / Satellite combination in a SIT 605 message, following the template in section 3.3
(“SIT 605 Status Message (Advising return to normal operations)” [ LEOSAR Accuracy]”) of
Annex D of the document C/S A.003.
At this time, all MCCs can return to the normal processing of alerts from this LUT / satellite
combination.
B.9.3
GEOLUT/GEOSAT Low Availability
As a part of the QMS, each nodal MCC monitors the availability of every combination of a
GEOLUT and GEOSAR satellite that includes a GEOLUT in its DDR.
When the combination of an associated GEOLUT and GEOSAR satellite fails to meet the
availability criteria specified in section 2.5.3 (“GEOLUT Availability Assessment, Status
Reporting and Follow-Up Actions”) of C/S A.003, the nodal MCC in whose DDR the LUT is
located:
• Sets the availability status indicator for that LUT / satellite combination on the Cospas-
Sarsat website to yellow.
• Sends a SIT 915 message to warn the MCC with which the LUT is associated of this
availability problem.
• Continues to monitor the availability of this LUT / satellite combination.

B-43

Section 2.1 (“SIT 915 Warning Message” [GEOSAR Availability]) of Annex D of the document
C/S A.003 contains a template for the narrative message that is used to warn an MCC when the
combination of an associated GEOLUT and GEOSAR satellite has failed to meet the availability
criteria.
This warning message is sent to request that the receiving MCC check its GEOLUT to determine
the cause of the reduced availability:
• If the GEOLUT is found to have a problem, then the system should be modified as
necessary to correct the problem. Once this has been done, the nodal MCC (and any other
MCCs that may have been affected) should be notified.
• If the investigation determines that there is no problem with the LUT, then the receiving
MCC should notify the nodal MCC and the Space Segment provider that is responsible for
the GEOSAR satellite involved, so that they can investigate and take action as appropriate.
If the combination continues to fail to meet the criteria for a three-day period, then the nodal MCC:
• Sets the availability status indicator for this LUT / satellite combination on the Cospas-
Sarsat website to red.
• Sends a SIT 605 message to notify all MCC of the non-conformance of the availability of
this GEOLUT / satellite combination.
• Continues to monitor the availability of that LUT / satellite combination.
The status message template in Section 2.2 (“SIT 605 Status Message (Advising non-conformity)”
[GEOSAR Availability]) of Annex D of the document C/S A.003 is used to notify all MCCs when
the combination of the GEOLUT and GEOSAR satellite that are identified in the message has
failed to meet the availability criteria over a three-day period.
This non-conformance message is sent to inform all MCCs of the problem. No action is required
of the receiving MCCs; however, they should be aware that this situation may result in the LUT
not being able to provide alert data in its nominal coverage area:
• It may not be able to provide data to confirm an alert that has been detected and located by
another LUT/satellite combination.
• It may not produce solution data at the predicted next time of visibility for any beacon that
has been detected and located.
The receiving MCC may also wish to check the Cospas-Sarsat website to see if there is any other
related problem with the LUT or satellite involved, and to see when the data produced by this
LUT/satellite combination returns to the nominal availability.
When the availability returns to the normal range and has passed the appropriate criteria, the nodal
MCC:
• Sets the availability status indicator for this LUT / satellite combination on the Cospas-
Sarsat website to green.

B-44

• Sends a SIT 605 message to notify all MCC of the return to conformance of the availability
of this GEOLUT / satellite combination.
The nodal MCC notifies the other MCCs of the return to conformance of the availability of the
GEOLUT / Satellite combination in a SIT 605 message, following the template in section 2.3
(“SIT 605 Status Message (Advising return to normal operations)” [GEOSAR Availability]) of
Annex D of the document C/S A.003.
B.9.4
MEOLUT Location Accuracy Status Messages
As a part of the QMS, each nodal MCC monitors the location accuracy of the Difference of Arrival
(DOA) solutions that are produced by every MEOLUT in its DDR for all of its designated
reference beacons. As long as it has at least 20 independent locations from any MEOLUT for all
the designated reference beacons, the nodal MCC in whose DDR the MEOLUT is located updates
the MEOLUT status on the Cospas-Sarsat website, following the location accuracy criteria
specified in section 2.5.5.2 (“MEOLUT Location Accuracy”) of C/S A.003.
Whenever the status changes, the nodal MCC sends a SIT 915 message to notify the MCC with
which the LUT is associated of this location accuracy change. It then continues to monitor the
location accuracy of this LUT.
When the status changes from green to yellow, a warning message is sent to the MCC associated
with the MEOLUT. Section 4.1 (“SIT 915 Message (Status changed from Green+ or Green to
Yellow)” [MEOLUT Location Accuracy]) of Annex D of the document C/S A.003 contains a
template for the narrative message that is used to warn an MCC when an associated MEOLUT is
failing to meet the location accuracy criteria.
This warning message is sent to request that the receiving MCC checks its MEOLUT to determine
the cause of the reduced location accuracy:
• The receiving MCC should process all alert messages from this MEOLUT and send them
to the nodal MCC, following the usual procedures, for continuing QMS processing.
• If the LUT is found to have a problem, then the system should be modified as necessary to
correct the problem. Once this has been done, the nodal MCC (and any other MCCs that
may have been affected) should be notified.
• If the investigation determines that there is no problem with the LUT, then the receiving
MCC should notify the nodal MCC, so that they can investigate further and take action as
appropriate.
Until the problem is resolved, the MCC processing of all alerts from this MEOLUT is based only
on the contents of the 406 MHz beacon message and does not use the independent location from
the MEOLUT.

B-45

When this MEOLUT fails to meet the location accuracy criteria and its status is changed to red,
then the nodal MCC:
• Continues to process alert messages from this MEOLUT following the usual procedures
for continuing QMS processing.
• Processes alert messages from this MEOLUT for distribution to all other MCCs based only
on the contents of the 406 MHz message from the beacon, and not on the independent
location solution produced by the LUT.
• Continues to monitor the location accuracy of this MEOLUT.
When the location accuracy status of the MEOLUT changes to red, the status message template in
Section 4.2 (“SIT 605 Status Message (Status changed to Red)” [MEOLUT Location Accuracy])
of Annex D of the document C/S A.003 is used to notify all MCCs that the MEOLUT identified
in the message has failed to meet the location accuracy criteria.
This non-conformance message is sent to inform all MCCs of the problem. Each receiving MCC
then processes alert messages from this MEOLUT based only on the contents of the 406 MHz
message from the beacon, and not on the independent location solution produced by the LUT.
During this period, they should be aware that this situation may result in the LUT not being able
to provide alert data in its nominal coverage area:
• It may not be able to provide data to confirm an alert that has been detected and located by
another LUT.
• It may not produce solution data at the predicted next time of visibility for any beacon that
has been detected and located.
Each receiving MCC may also wish to check the Cospas-Sarsat website to see if there is any other
related problem with the MEOLUT, and to see when the independent location data produced by
this MEOLUT returns to the nominal accuracy.
When the problem is resolved and the location accuracy returns to the normal range and has passed
the appropriate criteria, the nodal MCC changes the location accuracy status to green and sends a
SIT 605 message (following the template in section 4.3 (“SIT 605 Status Message (Status change
from Red to Green+ or Green)” [MEOLUT Location Accuracy]) of Annex D of the document C/S
A.003) to notify all MCCs of the return to conformance of the location accuracy of this MEOLUT.
At this time, all MCCs can return to the normal processing of alerts from this MEOLUT.
When the location accuracy status moves from red (failed) to yellow (not meeting the specification,
but within a reasonable range), the nodal MCC changes the location accuracy status and sends a
SIT 605 message (following the template in section 4.4 (“SIT 605 Message (Status changed from
Red to Yellow)” [MEOLUT Location Accuracy]) of Annex D of the document C/S A.003) to
notify all MCCs of this change of the location accuracy status of this MEOLUT. At this time, all
MCCs can return to the normal processing of alerts from this MEOLUT. However, the associated
MCC is asked to continue to investigate the status of its MEOLUT, and other MCCs should use
caution when sending alerts from this MEOLUT to a SAR destination.

B-46

B.9.5
MEOLUT Detection Probability Status Messages
As a part of the QMS, each nodal MCC monitors the detection probability of the Difference of
Arrival (DOA) solutions that are produced by every MEOLUT in its DDR for all of its designated
reference beacons. As long as it has at least 20 independent locations from any MEOLUT for all
the designated reference beacons, the nodal MCC in whose DDR the MEOLUT is located updates
the MEOLUT status on the Cospas-Sarsat website, following the detection probability criteria
specified in section 2.5.5.4 (“MEOLUT Detection Probability”) of C/S A.003.
Whenever the detection probability status changes to yellow or red, the nodal MCC sends a
SIT 915 message to notify the MCC with which the LUT is associated of this detection probability
change. Section 6.1 of Annex D of the document C/S A.003 contains a template for the narrative
message that is used to warn an MCC when an associated MEOLUT is failing to meet the detection
probability criteria.
This warning message is sent to request that the receiving MCC check its MEOLUT to determine
the cause of the reduced detection probability:
• If the LUT is found to have a problem, then the system should be modified as necessary to
correct the problem. Once this has been done, the nodal MCC (and any other MCCs that
may have been affected) should be notified.
• If the investigation determines that there is no problem with the LUT, then the receiving
MCC should notify the nodal MCC, so that they can investigate further and take action as
appropriate.
While the problem is being investigated, the receiving MCC should continue to process all alert
messages from this MEOLUT and distribute them to other MCCs, following the usual procedures
defined in the DDP.
The nodal MCC will also continue to process all alert messages from this MEOLUT and distribute
them to other MCCs, following the usual procedures defined in the DDP.
B.9.6
MEOLUT Location Probability Status Messages
As a part of the QMS, each nodal MCC monitors the location probability of the Difference of
Arrival (DOA) solutions that are produced by every MEOLUT in its DDR for all of its designated
reference beacons. As long as it has at least 20 independent locations from any MEOLUT for all
the designated reference beacons, the nodal MCC in whose DDR the MEOLUT is located updates
the MEOLUT status on the Cospas-Sarsat website, following the location probability criteria
specified in section 2.5.5.3 (“MEOLUT Location Probability”) of C/S A.003.
Whenever the location probability status changes, the nodal MCC sends a SIT 915 message to
notify the MCC with which the LUT is associated of this location probability change. It then
continues to monitor the location probability of this LUT.
When the location probability status changes from green to yellow, a warning message is sent to
the MCC associated with the MEOLUT. Section 5.1 of Annex D of the document C/S A.003

B-47

contains a template for the narrative message that is used to warn an MCC when an associated
MEOLUT is failing to meet the location probability criteria.
This warning message is sent to request that the receiving MCC check its MEOLUT to determine
the cause of the reduced location probability:
• If the LUT is found to have a problem, then the system should be modified as necessary to
correct the problem. Once this has been done, the nodal MCC (and any other MCCs that
may have been affected) should be notified.
• If the investigation determines that there is no problem with the LUT, then the receiving
MCC should notify the nodal MCC, so that they can investigate further and take action as
appropriate.
While the problem is being investigated, the receiving MCC should continue process all alert
messages from this MEOLUT and distribute them to other MCCs, following the usual procedures
defined in the DDP.
When this MEOLUT fails to meet the location probability criteria and its status is changed to red,
then the nodal MCC:
• Continues to process alert messages from this MEOLUT, following the usual procedures
from the DDP.
• Continues to monitor the location probability of this MEOLUT.
When the location probability status of the MEOLUT changes to red, the status message template
in section 5.2 of Annex D of the document C/S A.003 is used to notify all MCCs that the MEOLUT
identified in the message has failed to meet the location probability criteria.
This non-conformance message is a SIT 605 message that is sent to inform all MCCs of the
problem. The receiving MCCs then continue to process alert messages from this MEOLUT
following the usual procedures defined in the DDP. During this period, they should be aware that
this situation may result in the MEOLUT not being able to provide alert data in its nominal
coverage area:
• It may not be able to provide data to confirm an alert that has been detected and located by
another LUT.
• It may not produce solution data at the predicted next time of visibility for any beacon that
has been detected and located.
Each receiving MCC may also wish to check the Cospas-Sarsat website to see if there is any other
related problem with the MEOLUT, and to see when the independent location data produced by
this MEOLUT returns to the nominal location probability.
When the problem is resolved and the location probability returns to the normal range and has
passed the appropriate criteria, the nodal MCC changes the location accuracy status to green and
sends a SIT 605 message (following the template in section 5.3 of Annex D of the document C/S

B-48

A.003) to notify all MCCs of the return to conformance of the location probability of this
MEOLUT.
When the location probability status moves from red (failed) to yellow (not meeting the
specification, but within a reasonable range), the nodal MCC changes the location probability
status and sends a SIT 605 message (following the template in section 5.4 of Annex D of the
document C/S A.003) to notify all MCCs of this change of the location probability status of this
MEOLUT. The associated MCC is asked to continue to investigate the status of its MEOLUT.
B.9.7
MEOLUT Local Antenna Availability Status Messages
As a part of the QMS, each nodal MCC monitors the availability of the local antennas at every
MEOLUT in its DDR. As long as it has at least 20 independent locations from any MEOLUT for
all the designated reference beacons, the nodal MCC in whose DDR the MEOLUT is located
updates the MEOLUT status on the Cospas-Sarsat website, following the local antenna availability
criteria specified in section 2.5.5.5 (“MEOLUT Local Antenna Availability”) of C/S A.003.
Whenever the local antenna availability status changes to yellow or red, the nodal MCC sends a
SIT 915 message to notify the MCC with which the LUT is associated of this local antenna
availability change. Section 6.1 of Annex D of the document C/S A.003 contains a template for
the narrative message that is used to warn an MCC when an associated MEOLUT is failing to meet
the local antenna availability criteria.
This warning message is sent to request that the receiving MCC check its MEOLUT to determine
the cause of the reduced local antenna availability:
• If the LUT is found to have a problem, then the system should be modified as necessary to
correct the problem. Once this has been done, the nodal MCC (and any other MCCs that
may have been affected) should be notified.
• If the investigation determines that there is no problem with the LUT, then the receiving
MCC should notify the nodal MCC, so that they can investigate further and take action as
appropriate.
While the problem is being investigated, the receiving MCC should continue to process all alert
messages from this MEOLUT and distribute them to other MCCs, following the usual procedures
defined in the DDP.
The nodal MCC will also continue to process all alert messages from this MEOLUT and distribute
them to other MCCs, following the usual procedures defined in the DDP.
B.9.8
MEOLUT Timeliness Status Messages
As a part of the QMS, each nodal MCC monitors the timeliness ratio received by the MCC from
all MEOLUTs, at every MEOLUT in its DDR.

B-49

The timeliness ratio is defined in section 2.4.2.6 (“MEOSAR System Timeliness”) of C/S A.003
as the ratio of the number of solutions received from the MEOLUT within ten minutes to the total
number of solutions received by the nodal MCC from all MEOLUTs.
As long as it has at least 20 solutions from the MEOLUT, the nodal MCC in whose DDR the
MEOLUT is located updates the MEOLUT status on the Cospas-Sarsat website, following the
timeliness criteria specified in section 2.5.5.6 (“MEOLUT Timeliness”) of C/S A.003.
Whenever the local antenna availability status changes to yellow or red, the nodal MCC sends a
SIT 915 message to notify the MCC with which the LUT is associated of this local antenna
availability change. Section 8.1 of Annex D of the document C/S A.003 contains a template for
the narrative message that is used to warn an MCC when an associated MEOLUT is failing to meet
the timeliness criteria.
This warning message is sent to request that the receiving MCC check its MEOLUT to determine
the cause of its poor timeliness performance:
• If the LUT is found to have a problem, then the system should be modified as necessary to
correct the problem. Once this has been done, the nodal MCC (and any other MCCs that
may have been affected) should be notified.
• If the investigation determines that there is no problem with the LUT, then the receiving
MCC should notify the nodal MCC, so that they can investigate further and take action as
appropriate.
While the problem is being investigated, the receiving MCC should continue to process all alert
messages from this MEOLUT and distribute them to other MCCs, following the usual procedures
defined in the DDP.
The nodal MCC will also continue to process all alert messages from this MEOLUT and distribute
them to other MCCs, following the usual procedures defined in the DDP.
- END OF ANNEX B -

C-1

ANNEX C: LOCATION DATA CONCEPTS AND TERMINOLOGY
There are many terms that are unique to the description of the various parts of the Cospas-Sarsat
System. Some of these terms are defined or explained in the individual sections of this Annex.
C.1
LEOSAR Doppler Solution Processing
The LEOSAR solution processing is based on the Doppler effect, which changes the frequency of
the received signal as the satellite passes over the beacon.
C.1.1.1
Doppler Curve
As the satellite approaches the beacon, the received frequency is increased by the Doppler effect.
Then, as the satellite passes the beacon and moves away from it, the received frequency is
decreased. When the received frequency is plotted over time, the result is a Doppler curve, as
illustrated in Figure C.1.
Figure C.1: A Sample Doppler Curve
This illustration shows how the Doppler effect modifies the frequency of the signal that is received
from a distress beacon at a LEOSAR satellite.
The illustration also shows some of the key parameters that are used to define the Doppler curve
and the independent position estimate that is generated by the LEOLUT solution processing:
• The Time of Closest Approach (TCA, MF \#14) is the time when the satellite passes closest
to the beacon.

![Image 1 from page 223](/images/cospas-sarsat/G-series/G010/G010_page_223_img_1.png)

C-2

• The frequency bias (MF \#13) is the measure of the difference between the beacon
frequency at the TCA and the nominal beacon frequency of 406.000 MHz.
• The total Doppler shift (shown as “m” on right side of the diagram) is used in the solution
processing to determine how close the satellite comes to the beacon. It is not included in
any SIT message, but it determines the Cross-Track Angle (CTA, MF \#17). See
section C.1.2 of this Annex.
The Doppler curve that is determined by the set of time and frequency measurements collected by
the LEOLUT on a particular pass of a satellite over a beacon is identified by an iterative curve-fit
process. For each iteration, the TCA, CTA, and bias are adjusted until a good fit is achieved. The
number of iterations (MF \#16) is the count of the number of adjustments that are required to
identify the Doppler curve.
During the curve fit process, there are some limitations on the adjustments that may be made at
each step in the process. These are primarily the size of the adjustment: for each parameter, there
is a minimum adjustment, and any smaller adjustment is not considered significant. However, there
is an additional constraint on the CTA: to avoid an infinite sequence of jumps across the orbit
plane when the CTA is close to 0°, no CTA below a threshold value (normally around 1°) is allowed.
C.1.2
A and B Positions
The CTA is the measure of the angle at the centre of the earth, between the satellite and the beacon,
at the TCA. Since this angle could be on either side of the satellite orbit plane, the Doppler solution
processing produces two position estimates, one on each side of the satellite orbit. These two
positions are arbitrarily identified as:
• The A-position, which is the position that is considered to be more probably the correct
location, and
• The B-position, which is the position that is considered to be less probably the correct
location.
The A- and B- positions are normally distinct; the only exception is when the satellite passes
directly over the beacon, and the CTA is 0°. As noted above, the solution processing does not
normally allow the positions to converge at this value. However, with a very small CTA, the
two positions may be very close together.
C.1.2.1
LEOSAR Ambiguity Resolution
The existence of a solution with two different positions is an ambiguity that creates a requirement
to identify which of these positions is the correct position of the beacon. This process of
determining the correct position is called ambiguity resolution; it is addressed in section 4.3.4.4
and in section B.5.5 of this Handbook. The following paragraphs describe the ambiguity resolution
process in the Cospas-Sarsat System.
The first stage in the ambiguity resolution is performed in the LEOLUT. Because the Earth is not
still, but is rotating below the satellite, it produces a small Doppler effect on the received signal.

C-3

This effect is too small to show in a Doppler plane diagram (as shown in Figure C.1). However, if
the LEOLUT has enough data, and if that data is sufficiently accurate, the LEOLUT can use this
information to produce a probability (MF \#28): an estimate of the probability that the A-position
is the true location of the beacon.
The probability estimate generated by a LEOLUT is normally in a range of about 80% or higher.
While this is a useful value, it is necessary to find further information to decide which of the two
positions is the correct location for the beacon.
The next stage in the ambiguity resolution is done in the MCC. As the MCC receives more data
about a beacon, it can compare the positions to identify the correct position in the initial estimate.
This is a part of the processing of confirming a beacon solution. To positively resolve the
ambiguity of a LEOSAR Doppler solution, the confirming solution must be an independent
solution (that is, it must satisfy the conditions listed in section 4.3.4.4 of this Handbook) that
contains a position estimate that matches, to within the appropriate match criterion as listed in
section 4.2.2 (“Position Matching”) of the DDP, one of the Doppler position estimates.
For an MCC to be able to use two solutions to resolve the position ambiguity the two position
estimates must be independent, and they must be computed from satellites that are in different
orbital planes. This second condition requires that both of the A- or B- locations must be
significantly different from the corresponding location in the other solution. If both of the two
pairs of positions are too close together, as illustrated in Figure C.2, then these two solutions cannot
be used to resolve the Doppler solution ambiguity.
Figure C.2: Unresolved Doppler Match Scenario
This diagram (Figure 4.9, “Unresolved Doppler Match Scenario (20 km circles)”, from the DDP – C/S A.001)
illustrates a situation where the LEOSAR solution ambiguity cannot be resolved by two locations from
satellites that are in parallel orbit planes. The circles are 20 km in radius, consistent with the match criteria
specified in C/S A.001.

![Image 1 from page 225](/images/cospas-sarsat/G-series/G010/G010_page_225_img_1.png)

C-4

Although the usual method to resolve the ambiguity of a Doppler solution is to wait for an
independent solution to confirm one position estimate and to reject the image position, as described
above, an MCC (or an RCC) may be able to do so by other means, such as:
• The contact person (from the beacon register) may be able to provide this information.
• The nature of the beacon may provide a clue. (For example, an EPIRB carried on a large
ship should not be found in an inland location.)
• Overflying aircraft may be able to confirm reception of beacon signals from one of the
positions.
• Other reports (radio or telephone calls, for example) may provide information.
The results of these methods of resolving the ambiguity are not normally reported through the data
distribution network in a SIT message; they will more likely be relayed by the operator (in a
narrative message or a voice communication) to the RCC. However, if the occasion arose, an MCC
operator could manually generate a SIT message to report these results.
C.1.3
Time of Closest Approach (TCA)
As noted in section C.1.1.1 above and illustrated in Figure C.1, the Time of Closest Approach
(TCA) is the time when the satellite passes closest to the beacon. This time is used to determine
the position of the satellite when it passes closest to the beacon; from this, the LEOLUT can
compute the point on the surface of the Earth that is directly below the satellite (the sub-satellite
point), and use that to estimate the beacon position.
C.1.4
Cross-Track Angle (CTA)
As explained in section C.1.2 above, the Cross-Track Angle (CTA) is the measure of the angle at
the centre of the earth, between the satellite and the beacon, at the TCA. This value is used to
determine the distance from the sub-satellite point. With the known path and position of the
satellite, this distance is used by the LEOLUT to compute the position of the beacon.
C.1.5
Number of Points
For each beacon message that is relayed through the LEOSAR satellite, the LEOLUT collects the
data associated with that message:
• The contents of the beacon message,
• The measured frequency of reception of the signal at the LEOSAR spacecraft,
• The time of reception of the signal at the LEOSAR spacecraft.
Each such data set constitutes one point for the solution processing. Note that the data may be
received through either the SARP or the SARR instrument carried on the spacecraft; regardless,
each set of measurements is a single data point to be processed.

C-5

The number of points that is reported in MF \#21 (as defined in the SID, document C/S A.002) is
the final count of the points that are used in the computation of the beacon solution.
This number of points may not be the same as the total number of points available for use in the
solution computation. Some of these points may be rejected and not used; reasons for rejecting a
data point include:
• The frequency value may be out of the expected range.
• The frequency value may be an outlier in the data set (see below).
• The time value (for a SARR measurement) may be too far from the time when the
measurement is received.
• The time value (for a SARP measurement) may be out of the expected range.
• The frequency value may be an outlier in the data set (see below).
As the LEOLUT processes the time and frequency measurements, it determines how closely these
measurements fit a theoretical Doppler curve. If any of the measurements fall too far away from
the theoretical curve that best fits the data, then that set of measurements is discarded as an outlier.
After any point has been discarded, the process is repeated without that point.
After the processing has gone through enough iterations and has converged to a solution, the
number of points that were used in the final iteration is the count that is reported in MF \#21.
Partial Doppler Curves
A partial Doppler Curve is simply a truncated section of a Doppler curve. A LEOLUT may receive
the data from a partial Doppler curve for either of two reasons:
• Because of the location of the beacon and the curvature of the Earth (or local obstructions
around the LUT), the spacecraft may not be visible to the LUT for some part of the pass.
• Because of the obstruction caused by local objects in the signal path from the beacon, the
spacecraft may not receive the signals from the beacon for some part of the pass.
In both cases, the LUT has only a partial Doppler curve to work with.
C.1.6
Window Factor
Ideally, during each satellite pass, the LEOLUT should have one data point for each transmission
from the beacon. Unfortunately, this is often not possible. As noted in section 0 above, the
LEOLUT may only receive the data associated with a partial Doppler curve. Alternately, it must
be noted that a distress incident is not an ideal situation for a radio transmitter; the signal from the
beacon may be weak and may not always be detected by the processing on the spacecraft or in the
LEOLUT. Whatever the reason, the quality of the solution that is computed by the LEOLUT is
limited by the available data.

C-6

The Window Factor (WF, MF \#15) is one measure of the quality of the data that was available for
the LEOSAR solution computation.
If the data time span includes the point of inflection of the Doppler curve, the Window Factor is
set to zero. Otherwise, the value of the Window Factor is calculated according to the duration of
the data and the length of time between the centre point of the data (in time) and the point of
inflection of the Doppler curve. In the extreme case, with very few points at the end of the Doppler
curve, the value of the Window Factor will be nine.
The data that is used in the calculation of the Window Factor is illustrated in the diagram in Figure
C.3:
•  TCA is the time of closest approach of the satellite to the beacon, at the point of inflection
of the calculated Doppler curve.
• Centre is the centre point (halfway between the first and last point, in time) of the data.
• The time Separation, which equals the absolute value of (TCA-Centre), indicates the
separation of the data from the point of inflection.
• The time Duration is the duration (in time, from the first to the last data point) of the data
actually available for the Doppler processing.
The Window Factor is then equal to the integer part of ( 2 · Separation / Duration ). The
calculation of the Window Factor is based on the values of the parameters that are used to compute
the theoretical Doppler curve that is used to fit the measured data.
Figure C.3: Window Factor Calculation
In general, a solution that has a Window Factor of zero (that is, the data available for the
computation cover a span of time that includes the TCA) can be expected to produce a reasonably

![Image 1 from page 228](/images/cospas-sarsat/G-series/G010/G010_page_228_img_1.png)

C-7

accurate solution. In contrast, if the data points are all on the same side of the TCA, the solution
may be less accurate. The higher the Window Factor (that is, the further the data is, in time, from
the TCA), the less reliable the solution is likely to be.
C.1.7
Theoretical Number of Points for a Particular Satellite and CTA
The number of transmissions that a beacon can produce during a LEOSAR satellite pass is
determined by the altitude of the satellite orbit and the distance of the beacon from the satellite
orbit plane. Depending on the relative positions of the beacon, the spacecraft, and the LEOLUT,
the duration of the pass and the number of transmissions that might be received may vary over a
fairly wide range:
• The duration of the pass will be between zero minute and about eighteen minutes.
• The total number of transmissions during the pass will be between zero and twenty.
The LEOLUTs are generally configured to track the satellite that will provide the most data, and
not to track any satellite that will not be visible for more than five minutes.
To assist an MCC operator to understand what might be expected on a given LEOSAR satellite
pass, the document C/S A.003 (System Monitoring and Reporting) contains a Table C.3 (“Number
of Points Transmitted by a Distress Beacon”) in Annex C (“Performance Parameters for System
Self-Monitoring”) that lists the expected duration of each pass and the number of points that will
be transmitted during that period for a wide range of LEOSAR situations:
• For the COSPAS satellites (at 1000 km altitude) and SARSAT satellites (at 850 km
altitude)
• For horizon elevations of both 0° and 5°
For information, the table also lists the maximum elevation of the satellite during the pass. Thee
are all nominal values, based on the computation of the orbit and of the various parameters
reported. In operational conditions, the actual number of transmissions may be one or two more or
less than the nominal value in the table.
Because of the high altitude of the MEOSAR orbits and the large number of satellites, a MEOLUT
can always expect to see several spacecraft at all times. For this reason, a similar table has not been
prepared for the MEOSAR satellites.
Because of the nature of the geosynchronous orbit, a GEOSAR satellite will always remain visible
to the GEOLUT that is tracking it. The GEOLUT can expect to receive every transmission from a
beacon that is within the view of the GEOSAR spacecraft. No table of visibility is required.

C-8

C.1.8
Next Time of Visibility
The time reported for next time of visibility in MF \#29 depends on the system that generated this
alert message:
• For the LEOSAR system, this field indicates the next time of Loss of Signal (LOS) when
the position is expected to be visible in local mode to a LEOSAR satellite that will be
tracked by this LEOLUT. If the information is not available, the default value is used.
• For the MEOSAR system, the default value is provided.
• For the GEOSAR system, this field indicates the next time of LOS when the position is
expected to be visible to a LEOSAR satellite. If the information is not available, the default
value is used.
C.2
MEOSAR Difference of Arrival (DOA) Solution Processing
The MEOSAR solution processing is based on the observed differences in the Time of Arrival
(TOA) and the Frequency of Arrival (FOA) of the messages from the distress beacon at the
spacecraft. Since the time and frequency are not measured by the SARR instrument on the
MEOSAR satellites, they must be measured and computed in the MEOLUT:
• The TOA is the time when the message is received at the spacecraft. The time is measured
when the message is received at the MEOLUT. The TOA is then computed in the
MEOLUT by determining, based on the known orbit of the satellite and the characteristics
of the instrument on the spacecraft, the delay between the time of arrival at the satellite and
the time of arrival at the LUT. For a message that is received from a remote antenna, this
value (presented as a negative number) is the Time Offset: Message Field number 69 in
the SID (document C/S A.002). That time offset is added to the time measured at the
MEOLUT to get the TOA.
• The FOA is the frequency of the signal that carries the message from the distress beacon,
as it is received at the spacecraft. The FOA is then computed in the MEOLUT by
determining, based on the known orbit of the satellite and the characteristics of the
instrument on the spacecraft, the frequency change between its reception at the satellite
and the measurement at the LUT. For a message that is received from a remote antenna,
this is the Frequency Offset: Message Field number 70 in the SID (document C/S A.002).
That frequency offset is added to the frequency measured at the MEOLUT to get the FOA.
With the TOA and FOA data from several different MEOSAR satellites, the MEOLUT can
compute the Difference of Arrival (DOA) position of the beacon.
C.2.1
Multilateration
Although the term trilateration has been used to describe the MEOSAR DOA solution processing,
the processing actually uses a multilateration algorithm; trilateration is a simplified algorithm that
uses angles to determine a location in a two-dimensional Cartesian space.

C-9

Multilateration (more completely, pseudo range multilateration) is a navigation and surveillance
technique based on measurement of the TOAs of energy waves (for the Cospas-Sarsat MEOSAR
system, radio waves) having a known propagation speed. Because the speed of propagation is
known, the difference in the arrival times of the signal can be directly converted into a difference
in the distances from the transmitter to each of the receivers. With enough information, this
information can then be used to compute the location of the transmitting beacon.
C.2.2
Single Burst Solution
The multilateration algorithm is capable of producing a beacon position estimate with the data
from a single beacon burst: one message transmitted by the beacon.
The difference between the arrival times of a beacon message at two different spacecraft at known
locations is used to determine a two-sheeted hyperboloid curve on which the beacon is located.
Data from a third spacecraft will generate a new hyperboloid. The intersection of these two
hyperboloids with the surface of the Earth produces a position for the transmitting beacon. With
data from a third spacecraft, the intersection with the Earth’s surface is not required, and a three-
dimensional position (including altitude) can be computed.
Of course, the accuracy of the solution that is produced by these computations is limited by the
accuracy of the available data. However, if more spacecraft are available, the additional
measurements of the time of arrival from each of the spacecraft can be used to improve the
accuracy of the computed position estimate.
C.2.3
Multi-Burst Solution
Each Cospas-Sarsat distress beacon transmits several messages over a period of time:
• A first-generation beacon (FGB) transmits one message every fifty seconds. This
specification was designed to enable the beacons to be detected by the LEOSAR system,
operating over a single satellite pass of fifteen minutes or less.
• A second-generation beacon (SGB) follows a similar pattern, but the rate of transmission
of messages varies over time. The intent of this variation is to enable the users of SGBs to
benefit from the ability of the MEOSAR system to compute an independent DOA position
estimate from a single burst: the beacon transmits many messages when it is first turned
on, and then switches to a slower rate as time passes.
Although each single-burst solution is computed independently, the MEOSAR system can also
compute a multi-burst solution. This can be done either by performing the solution processing on
a data set that includes measurements from more than one beacon message transmission, or by
computing several single-burst solutions and then merging them into a combined multi-burst
solution.
The second version of this process is essentially very similar to the solution merge processing that
is done in some MCCs. And it can be performed in the MEOLUT or in an MCC. The initial

C-10

implementation of the MEOSAR system makes use of the merging of single-burst solutions, for a
variety of reasons:
• An MCC has more solution data (from multiple MEOLUTs) to work with than a single
MEOLUT; as a result, the combination of multiple single-burst solutions might be expected
to provide better results.
• The software to merge individual solutions already exists in many MCCs, so the cost of
implementing this approach is lower than developing new software to process data from
multiple messages to generate one solution in a MEOLUT.
C.2.4
MEOLUT Configuration
To perform the Difference of Arrival (DOA) processing, a MEOLUT must receive and process
data from several MEOSAR satellites (at least four satellites, and preferably six or more) at the
same time. This can be achieved in a number of different ways:
• The MEOLUT can be designed with multiple tracking antennas and point each antenna to
track a different satellite.
• The MEOLUT can be designed with a single phased array antenna, which can track
multiple satellites simultaneously. Individual beams of this phased array antenna can then
track separate satellites.
• A network of MEOLUTs can share their antennas, so that all the MEOLUTs have access
to the data from all the antennas.
• The MEOLUT can be networked with other MEOLUTs, and this network of MEOLUTs
can share the data that is collected by each individual MEOLUT. This can be done with
several MEOLUTs that are operated by the same Ground Segment Provider, or it can be
done by networking MEOLUTs that are operated by different Ground Segment Providers.
Every one of these configurations is used by one or more of the Ground Segment Providers in the
Cospas-Sarsat MEOSAR system.
C.2.4.1
Networked Antennas
The European Union (EU) operates three MEOLUTs, which are located in Maspalomas (Canary
Islands, Spain), Spitsbergen (Norway), and Larnaca (Cyprus). There are four tracking antennas at
each location, and each antenna is controlled by the local MEOLUT at the same site. The EU has
a central processor that prepares a coordinated schedule for all of these MEOLUTs, to avoid
duplication of effort and to ensure the maximum coverage of the entire European area of
responsibility for Search and Rescue.
All three of the EU MEOLUTs are capable of reading data that is collected through the receivers
that are connected to all of the twelve available antennas. The result is that each European
MEOLUT is, effectively, a twelve-antenna MEOLUT with its antennas spread around the desired
coverage area.

C-11

Because each of the MEOLUTs can independently receive data from all of the antennas, the
complete configuration (consisting of one MEOLUT processor and twelve antennas and receivers)
of each MEOLUT has been separately commissioned and accepted into the Cospas-Sarsat Ground
Segment.
C.2.5
MEOSAR Quality Assessment
The MEOAR DOA processing produces three related quality indications with each solution:
• MF \#78
Quality Factor,
• MF \#84
Quality Indicator,
• MF \#89
Expected Horizontal Error.
These are each described in the SID.
The Quality Factor is a three-digit number that indicates the quality of the solution. The algorithm
for computing this quality factor is not defined by Cospas-Sarsat; it is left to the designer of the
individual MEOLUT to determine how it should be computed. However, a higher number is
required to indicate a better-quality solution.
The Quality Indicator identifies some specific characteristics that may affect the quality of the
solution:
• Bit 0 (value = 1):
single burst position confirmed,
• Bit 1 (value = 2):
single burst position not confirmed,
• Bit 2 (value = 4):
DOA position outside satellite footprint.
Since each characteristic is indicated by a single bit, these characteristics can be combined in the
Quality Indicator that is stored in MF \#84.
The Expected Horizontal Error (EHE) is a more precise estimation of the accuracy of a DOA
location. The EHE is explained in detail in section C.5.2 of this Handbook.
C.2.6
Uncorroborated Alerts
During the initial implementation of the MEOSAR system, the first MEOLUTs were observed to
generate a large number of uncorroborated alerts. An uncorroborated MEOSAR alert is:
• An unlocated MEOSAR alerts,
• That is generated from a single beacon message transmission that was relayed through a
single satellite channel,
• That contains a beacon identifier that does not match any previous message received at the
MEOLUT.

C-12

These alerts appeared to be associated with the reception of distorted (and invalid) messages from
a real beacon.
Since the beacon messages were not valid and the independent location estimate was not available,
these uncorroborated alerts were of little or no use to the SAR community. For this reason,
document C/S A.001 (Data Distribution Plan) specifies (in section 4.2.1.4, “Uncorroborated
MEOSAR Alerts”) that an MCC should suppress the distribution of such messages. This section
of the DDP includes a description of a few exceptional circumstances when an uncorroborated
MEOSAR alert should be distributed.
C.3
Two-Line (Orbital) Elements (TLE)
The Two-Line (Orbital) Elements (TLE) format was developed by the North American Aerospace
Defense Command (NORAD) for the transmission of the orbital elements of objects that are in
Earth orbit. The details of this format, and the meaning of each field in the two lines of text that it
defines, are listed in the Tables under MF \#85 and 86 of Appendix B.1 To Annex B (“Message
Field Definition”) in the SID (document C/S A.002).
The TLE include the orbital data to sufficient precision that they can be used by the Cospas-Sarsat
LUTs and MCCs for all types of satellites that are used in the System. However, they are primarily
used for the transmission of MEOSAR satellite orbital data.
C.4
Moving Beacons
The Cospas-Sarsat System was originally designed for the detection of beacons that are involved
in distress incidents. The expectation was that, in most cases, these beacons are in fixed locations,
and will not move during the period when they are active.
However, there are many situations when a distress beacon may move while it is active:
• During a maritime distress incident, a beacon is activated at sea:
-
The beacon will frequently be tossed (sometimes violently) by the wave action of a
storm.
-
The beacon may drift slowly with the currents and tides of the sea.
• With the advent of the ICAO Global Aeronautical Distress and Safety System (GADSS),
beacons may be activated while carried on aircraft travelling at relatively high speeds.
The slow motion of beacons at sea was not enough to disturb the computation of the independent
beacon location using the LEOSAR Doppler algorithms. However, the MEOSAR DOA
processing, which uses more precise measurements and can produce more accurate results, is more
sensitive to beacon motion.
During the MEOSAR Demonstration and Evaluation (D&E) phase, it was found that the
independent location data that was computed by the MEOLUTs for a moving beacon was not
accurate enough to meet the specifications defined in C/S T.019, “Cospas-Sarsat MEOLUT
Performance Specification and Design Guidelines”, which did not recognize the different

C-13

circumstances of a moving beacon. Since then, the MEOLUT specifications have been updated to
explicitly identify (in section 5.6, “Location Accuracy”) the requirements for the location of
beacons under different conditions:
• The accuracy requirements for nearly-static beacons (moving at less than 0.5 metres per
second) are defined in sections 5.6.1 and 5.6.2.
• The accuracy requirements for slow-moving beacons (moving at between 0.5 metres per
second and 10.0 metres per second) are defined in sections 5.6.3 and 5.6.4.
• The accuracy requirements for fast-moving beacons (moving at greater than 10.0 metres
per second) are defined in sections 5.6.5 and 5.6.6.
The final details of the requirements for moving beacons (including the distinctions between static,
slow-moving, and fast-moving beacons) are still (in 2023) being defined, but they are expected to
be close to, but not the same as, those for static beacons.
C.5
Independent Location Accuracy Estimates
With each independent location solution that is generated by a LUT, the LUT also produces a
location accuracy estimate. The nature of this accuracy estimate depends on the source of the
location data:
• A LEOLUT computes error ellipses, which is an estimate of the accuracy of the positions
in its Doppler solution.
• A MEOLUT computes the Expected Horizontal Error (EHE), which is an estimate of the
error that might exist in each single-burst solution that it calculates.
Both types of LUT also summarize this accuracy data into a single value, called a confidence
factor, which is reported to the MCC (and forwarded to the SPOCs and RCCs) as Message
Field # 30.
These location accuracy estimates are all defined in Appendix B.1 To Annex B (“Message Field
Definition”) in the SID (document C/S A.002).
C.5.1
LEOSAR Error Ellipse
A LEOLUT quantifies the accuracy of its Doppler location values in an error ellipse; an ellipse
centred on the computed beacon position that is expected to contain the true position of the beacon
50% of the time. This error ellipse is specified in MF # 27 as:
•
Angle
The angle between the true north and the major axis of the ellipse,
•
Semi-major axis
Half the length of the long axis of the ellipse,
•
Semi-minor axis
Half the length of the short axis of the ellipse.
The value of the error ellipse parameters is reported, but not verified, during the commissioning
of a LEOLUT.

C-14

The nature of the error of a Doppler solution is usually determined by the accuracy of the time and
frequency measurements that are used to compute the solution:
• An error in the measurement of the time of reception of the beacon message results in a
position error that is parallel to the direction of the satellite orbit.
• An error in the measurement of the frequency of reception of the beacon message results
in a position error that is perpendicular to the direction of the satellite orbit.
For each solution, the error ellipse is computed from the statistical variation of the measured data
that is used to generate the position estimates.
C.5.2
MEOSAR Expected Horizontal Error
The accuracy of each MEOSAR single-burst solution is determined by a number of factors:
• The configuration of the satellites that relayed the data from the beacon to the MEOLUT,
• The number of spacecraft that are available to relay the beacon messages,
• The statistical consistency of the data measurements.
The MEOLUT uses these factors to compute the Expected Horizontal Error (EHE); an estimate of
the error that might exist in each single-burst solution that it calculates.
For each MEOSAR DOA (Difference of Arrival) location, RCCs and SPOCs are provided with
the EHE value. This EHE value is the radius of the circle centred on the MEOSAR DOA location
that should contain the true beacon location with a 95% probability. In other words, there is a 95%
probability that the location error, which is defined as the distance between the MEOSAR DOA
location and the actual beacon location, is lower than the EHE value.
Figure C.4 illustrates the configuration for which the MEOSAR DOA location error is lower than
the associated EHE value, with the corresponding confidence percentage.
The EHE specification is further refined to ensure that EHE values associated with MEOSAR
DOA location provide a confident reflection of the location error, and in particular that the EHE
does not overestimate the location error in any significant way.
In addition to the 95% confidence requirement, the EHE values associated with the MEOSAR
DOA location provided to an RCC or a SPOC must be smaller than 2 times the associated EHE
value 99% of the time. In other words, there may only be a maximum 1% probability that the
MEOSAR DOA location error is greater than 2 times the EHE value. Figure C.5 and Figure C.6,
below, illustrate these two limits on the range of the DOA location error.

C-15

Figure C.4: MEOSAR DOA Location Error
The basic definition of the Estimated Horizontal Error (EHE) is illustrated for the case when the
actual error is smaller than the associated EHE value.
Figure C.5: Range Limits for DOA Location Error
This illustration shows the probabilities that the actual location error will be inside each of the
minimum and maximum values defined by the Estimated Horizontal Error (EHE).

![Image 1 from page 237](/images/cospas-sarsat/G-series/G010/G010_page_237_img_1.png)

![Image 2 from page 237](/images/cospas-sarsat/G-series/G010/G010_page_237_img_2.png)

C-16

Figure C.6: DOA Location Error
This illustration shows, in three dimensions, the probability that the actual beacon location will be
within the circles of radius EHE and 2\*EHE.
The EHE is normally computed in the MEOLUT, using the available information about the
satellite configuration (the Dilution of Precision, or DOP) and the statistics on the accuracy of the
time and frequency measurements that have been used in the computation of the DOA locations.
C.5.3
Confidence Factor (CF)
For both types of independent locations, the LUT also produces a Confidence Factor (MF \#30).
This Confidence Factor classifies the expected error in the position into a small number of
categories, as listed in the entry for MF \#30 in Appendix B.1 To Annex B (“Message Field
Definition”) in the SID (document C/S A.002).
C.6
Large Location Errors and Possible Causes
Although the Cospas-Sarsat LUTs are designed to produce the best quality results possible, and
the location accuracy of the independent position estimates is generally very good and meets the
requirements of the LEOLUT and MEOLUT specifications (document C/S T.002 and C/S T.019,
respectively), there are occasionally cases where the LUT produces a solution with a large location
error. For these purposes, a large location error is defined as a position estimate that is more than
fifty kilometres from the true beacon location.
During the commissioning of a LUT, the accuracy of every solution is verified, and any
independent location estimate that is more than fifty kilometres from the (known) true beacon
position requires an explanation in the commissioning report.

![Image 1 from page 238](/images/cospas-sarsat/G-series/G010/G010_page_238_img_1.png)

C-17

Some of the reasons for large location errors in the positions reported by the Cospas-Sarsat System
are described in the following paragraphs.
C.6.1
Encoded Location Data
The encoded location data in the beacon message is generated by the beacon, based on either:
• A Global Navigation Satellite System (GNSS) in the beacon,
• An external navigation system on the vessel that carries the beacon.
The existing GNSS systems are well understood, and the potential causes of error in the results
that these systems produce include:
• The inability of the beacon to receive the navigation signals from enough GNSS satellites,
usually caused by obstructions around the beacon after a distress incident,
• The inability of the beacon to remain operational for enough time to collect data and
compute a position.
Despite these potential problems, the vast majority of GNSS locations are reliable and accurate.
Since the nature of the external navigation system is not known, it is not possible to include any
comments on the potential causes of errors in the data that such a system might produce.
In addition to any errors that may be generated by the source of the data, the formatting of the
Cospas-Sarsat SIT messages for the transmission of the incident alert data may also force errors in
the encoded location data. For the first-generation beacons, the amount of space available in the
beacon message is limited (as specified in C/S T.001).
The encoded location data is generally divided into two sections:
• A coarse location estimate is provided in the available bits in the first protected field of the
message.
• An offset to a finer (more accurate) location is provided in the second protected data field,
in the extended message are of a long message.
Because of the limitations of the data field sizes in these message formats, the precision of the data
is restricted, as indicated in Table .

C-18

Table C-1: FGB Encoded Location Precision
This table indicates the precision of the encoded location data in the various beacon message formats;
this is the maximum accuracy that can be shown in a FGB alert message.
Protocol
Precision
(Minutes & seconds)
Maximum Error
(kilometres)
User Location
2’  0”
3.7
Standard Location
(coarse)
7’ 30”
13.9
Standard Location
(fine)
0’  2”
0.06
National Location
(coarse)
1’  0”
1.9
National Location
(fine)
0’  2”
0.06
RLS (coarse)
15’  0”
27.8
RLS (fine)
0’  2”
0.06
For each of these protocols (except for the User Location Protocol), the coarse location is available
if only the first protected field of the message is received successfully by the LUT. If both the first
and second protected fields of the beacon message are received successfully, then the fine
resolution is available.
Since the accuracy of a GNSS navigation system (or most other navigation systems) is usually
significantly better than the FGB protocols can hold, the accuracy of the encoded location is
normally limited by the available space in the beacon message. However, when the GNSS system
produces a position with a large error (for any of the reasons described above), that error will be
transmitted to the MCC.
Additional information:
According to document C/S T.001 section “Internal Navigation Device Performance”, for FGBs
coded with the Standard, National, or RLS Location protocols, the GNSS receiver accuracy must
be below 500m.
For suspected moving beacons, MCC operators should take into account that the beacon may have
drifted between the time the GNSS position has first been encoded in the beacon message and the
time a new GNSS position information is sent to the RCC or SPOC within a SIT 185 message
including this GNSS position.
Specifically, for FGBs other than ELT(DT)s in in-flight mode:
1.
a maximum 52.5-second period (up to 120-second period for ELT(DT) in post-crash mode)
may occur between the time the GNSS receiver processes the GNSS position and the time
this position is encoded in the beacon burst and sent to the satellite;

C-19

2.
the refresh rate of the internal GNSS receivers is defined such as:
a)
new beacons type-approved after 2022 should update their GNSS location between 4
minutes 25 seconds and 15 minutes (i.e., the GNSS position provided in a new SIT
185 message can be up to 15-minute old),
b)
new beacons type-approved between 2014 and 2022 should update their GNSS
location at least once every 30 minutes (i.e., the GNSS position provided in a new SIT
185 message can be up to 30-minute old),
c)
it is not specified for beacons type-approved before 2014 (i.e., the GNSS position
provided in a new SIT 185 message can be more than 30-minute old).
Consequently, RCCs and SPOCs may receive SIT 185 messages updating the beacon
position information for which only the independent position (i.e., the DOA or the Doppler
position) has been updated, and therefore, still containing GNSS position information that
has been refreshed several minutes prior to the timestamp indicated in the SIT 185 message.
For most beacons, the refresh rate of their internal GNSS receiver is available on the Cospas-
Sarsat
website
at
https://www.cospas-sarsat.int/en/beacons-pro/experts-beacon-
information/approved-beacon-models-tacs?view=tac\_beacons, selecting the TAC number
and searching for the field “Encoded Position Data Update Interval [or Fix]”.
(See also sections “GNSS Positions”, “Source of GNSS Position Data” and “Summary Guidance
for the Use of Position Data” of document C/S G.007.)
C.6.2
Doppler Location Data
The LEOSAR Doppler solution processing may produce a large location error in some of the
following circumstances:
• A small number (four or fewer) of data points available for the solution processing
-
See the description of MF \#21 in Appendix B.1 To Annex B (“Message Field
Definition”) in the SID (document C/S A.002).
-
This may be due to a beacon that is far away from the LUT (for a local mode solution).
-
It may also be caused by obstructions around the beacon, that prevent the beacon
message from reaching the satellite.
• A low Cross-Track Angle (CTA) (less than two degrees)
-
See MF \#17 in Appendix B.1 To Annex B (“Message Field Definition”) in the SID
(document C/S A.002),
-
A low CTA indicates that the satellite has passed directly over the beacon; in this
situation, the effects of small errors in the measurements are magnified.
• A high Cross-Track Angle (CTA) (greater than thirty degrees)
-
See MF \#17 in Appendix B.1 To Annex B (“Message Field Definition”) in the SID
(document C/S A.002),

C-20

-
A high CTA indicates that the satellite is far away from the beacon; in this situation, it
may have difficulty getting good frequency measurements.
• A high Window Factor (WF) (greater than two)
-
See MF \#15 in Appendix B.1 To Annex B (“Message Field Definition”) in the SID
(document C/S A.002),
-
If the data does not include measurements near or around the Time of Closest
approach, then the effects of small errors in the measurements are magnified.
If more than one of these circumstances applies to any given solution, the possibility of a large
location error is significantly increased.
C.6.3
DOA Location Data
The MEOSAR DOA solution processing may produce a large location error in some of the
following circumstances:
• Data available from only a small number of satellites
-
If data measurements are not available from at least three satellites, the MEOLUT
cannot compute a DOA solution. With data from only three or four satellites, the
accuracy of the solution will be limited.
-
This may be caused by obstructions around the beacon, that prevent the beacon
message from reaching some of the available satellites.
-
It may also occur when the beacon is far from the MEOLUT, so that very few satellites
have visibility of both the beacon and the MEOLUT.
• A high Dilution of Precision
-
Dilution of Precision (DOP) is a term that is used in satellite navigation to specify the
error propagation as a mathematical effect of navigation satellite geometry on
positional measurement precision.
-
The DOP is the ratio of the error in the computed location to the error in the data
measurements that are used to compute the location. If the DOP is high, the expected
error will be high.
-
There are a number of different ways to express the DOP:
▪
HDOP – horizontal dilution of precision,
▪
VDOP – vertical dilution of precision,
▪
PDOP – position (3D) dilution of precision,
▪
TDOP – time dilution of precision,
▪
GDOP – geometric dilution of precision.
-
The HDOP is used in the computation of the Expected Horizontal Error (EHE) of a
MEOSAR DOA solution.

C-21

-
Factors that increase the DOP (indicting that a larger position error may be expected)
include:
▪
A low number of satellites (four or fewer),
▪
Satellite alignment (in a line that is straight or almost straight).
If more than one of these circumstances applies to any given solution, the possibility of a large
location error is significantly increased.
Because the DOP includes the effects of the number of satellites on the solution accuracy, it (in
the form of the HDOP) is used to compute the EHE of the MEOSAR DOA position estimates.
- END OF ANNEX C -

D-1

ANNEX D: CONTINGENCY PROCEDURES
D.1
Operational Backup
As noted in sections 4.1.2 and 5.2.5 of this Handbook, each MCC is expected to have in place
suitable arrangements for backup capability, to be put into effect whenever the MCC cannot satisfy
these requirements. As explained in the following sections of this Annex, this backup may be
provided by:
• A separate MCC system that is maintained and operated by the administration of the
Ground Segment Provider that operates this MCC, which can be put into service when the
primary MCC is not operational,
• An arrangement with a neighbouring MCC to provide the MCC services when this MCC
is not operational.
Each of these backup arrangements is discussed in one of the following sections of this Annex.
The following sections of this Handbook then provide information about the special concerns that
are associated with:
• An MCC that is relying on its backup for a long period of time,
• Backup arrangements within a Data Distribution Region (DDR), and
• The backup of a nodal MCC.
The MCC specifications (in sections 5.9, “Backup Timing”, and 5.10 , “Additional Timing
Requirements”, of document C/S A.005) require that the switch-over between an MCC and its
backup facility, whether it is operated by the same administration or it is a foreign MCC, shall be
completed within thirty minutes of notification of the requirement for the backup. And the
implementation of backup procedures should never allow the delivery of alert messages to be
interrupted for more than one hour.
When an MCC switches its operations to a backup facility, it must notify other participants in the
Ground Segment of this change. The status message SIT 605, defined in the SID (document
C/S A.002) and described in section A.7.5.1 of this Handbook, is used for this purpose.
Whether or not a back-up facility available from the MCC administration, all MCCs prepare a plan
to hand over responsibility for their Service Area to another MCC in the event that the equipment
or services that are used at the operational MCC are not able to continue to provide the necessary
level of service. A description of the backup plans for each MCC is contained in section 5.3
(“Description of Cospas-Sarsat MCCs”) of document C/S A.001, “Cospas-Sarsat Data
Distribution Plan”.

D-2

Regardless of the backup arrangement that is in place for an MCC, the Programme requires that
the backup be tested on a regular basis. Unless the back-up arrangements have been called upon
operationally, they must be tested at least once a year. The schedule and the results of the backup
test are reported in the annual Report on System Status and Operations, which is submitted by each
Cospas-Sarsat Participant, and which is reviewed at each meeting of the Cospas-Sarsat Joint
Committee.
D.1.1
Internal Back-up MCC
Several Ground Segment Provider administrations have decided that they wish to provide a
complete MCC service, including backup facilities, within the scope of their own contributions to
the Cospas-Sarsat Ground Segment. These administrations have installed two complete MCC
facilities; sometimes these facilities are at separate locations, to avoid the risk of a single event
disabling both MCC facilities.
When an administration provides a second MCC facility, it should verify that this backup facility
is fully capable of providing all of the services of a Cospas-Sarsat MCC. In theory, this would
require that the backup facility go through a complete separate MCC commissioning test. In
practice, most administrations only formally commission their primary MCC facility, and then
separately verify (following their own internal test and verification procedures) that the backup
MCC facility is fully compatible with the primary MCC. Although there is no explicit acceptance
of this procedure in the Cospas-Sarsat documents, this process has been used for the many backup
MCCs that are currently available in the System. Implicitly, it has been found to be acceptable to
the Cospas-Sarsat Programme.
D.1.2
Backup Another MCC
An MCC that does not have a backup facility operated by the same administration (and, in fact, all
MCCs that do have their own backup facility) must make arrangements with a neighbouring MCC
to provide the backup support that is required in the case of the failure of the MCC.
The arrangements for the backup of an MCC by a foreign MCC should be documented in a written
agreement between the administrations that operate the MCCs and should be recorded in the
entries for both MCCs section 5.3 (“Description of Cospas-Sarsat MCCs”) of document
C/S A.001, “Cospas-Sarsat Data Distribution Plan”. The backup plan must be tested annually, and
the results of each backup test should be reported by both MCCs in their annual Report on System
Status and Operations.
D.1.3
Long Term Backup
The intent of the backup arrangements described above is to provide continuity of service when
an MCC is unable to perform its normal duties. However, if the failure of an MCC continues for
an extended period of time, these backup procedures place an untenable stress on the MCC that is
providing the backup, and some other form of relief is required. This is addressed in section 6.3.4
(“Determining the Status of Operational Ground Segment Equipment”) of document C/S A.003.

D-3

If an MCC remains in a non-operational state (as would be the case if it required backup) for more
than forty-five consecutive days, or if it does not maintain operational status for more than six
months within a one-year (twelve-month) period, then the nodal MCC that is responsible for the
Data Distribution Region (DDR) in which the non-operational MCC is located (the associated
nodal MCC) declares that non-operational MCC is in a “commissioned, not operational” (CNO)
state. The nodal MCC sends a SIT 605 message to notify all MCCs of this change of status.
The procedures described in section 3.7.4 (“Long-term Backup and Restoration of Operations”) of
the DDP (document C/S A.001) are followed to determine when an MCC is declared in CNO
status. Within the first forty-five days, the associated nodal MCC is notified that the problem that
required the backup is a long-term issue, and that associated nodal MCC begins to prepare a plan
to re-assign the responsibilities of the CNO MCC. This plan must address changes to the data
distribution system to:
• Treat the country that operates the NCO MCC as a SPOC of the nodal MCC or of another
MCC in the DDR,
• Assign each SPOC of the NCO MCC to another MCC in the DDR.
At this time, the nodal MCC notifies all other MCCs of the issue. This allows the other MCCs in
the DDR to prepare to take over the work of the NCO MCC, as necessary. If the failure continues
for another forty-five days (or a shorter period, as determined by the nodal MCC and agreed by
the other MCCs in the DDR), the nodal MCC then coordinates the implementation of the plan that
it has prepared.
The nodal MCC sends out a SIT 605 message to notify all Ground Segment Providers of the new
configuration. The Cospas-Sarsat Secretariat is also notified, and the status of the MCC is changed
on the Cospas-Sarsat website and in the appropriate System documents.
This configuration remains in effect until the NCO MCC is returned to Full Operational Capability
(FOC), as confirmed by a partial or complete re-commissioning of that MCC. See section 2.5
(“Recommissioning of a Previously Commissioned MCC”) of document C/S A.006 “MCC
Commissioning Standard” for the procedure for the re-commissioning a CNO MCC. At that time,
the original configuration (or a new configuration agreed by the nodal MCC and any other affected
MCC) takes effect, and the nodal MCC sends another SIT 605 message to notify all Ground
Segment Providers of this new configuration.
D.1.4
Backup in the Same DDR
Aside from nodal MCCs, the backup for an MCC is almost always performed by another MCC in
the same DDR.

D-4

D.1.4.1
Nodal MCC Backup
Some nodal MCCs operate dual MCC equipment systems, so that they have an internal backup
available in the event of a failure of the primary MCC equipment:
• The AUMCC (Australian MCC) is co-located with the RCC Australia in Canberra. They
have a disaster recovery plan and if conditions are such that the primary site has to be
abandoned then personnel will be transferred to an alternative site that is set up to support
most of the RCC functions and some AUMCC functions.
• The USMCC (United States of America MCC) is located in Suitland, Maryland. The USA
has a complete alternate MCC equipment at Wallops Island in Virginia. This provides a
fully operational set of MCC equipment and communications access at a geographically
separate site. The MCC personnel can move from the primary site in Suitland to the backup
site on Wallops Island within half an hour of the decision to switch to the backup site.
In addition, every operator of a nodal MCC has a backup agreement with another administration
to provide data distribution services in the event of a failure at their MCC.
In order to assure that the backup can provide all of the same services as the original MCC, the
backup for a nodal MCC is almost always another nodal MCC:
• The USMCC backs up the AUMCC.
• The FMCC backs up the CMC (Cospas Mission Control, in Russia).
• The SPMCC backs up the FMCC.
• The USMCC backs up the JAMCC.
• The FMCC backs up the SPMCC.
• The AUMCC backs up the USMCC nodal functions.
Note that the USA has two separate backup agreements:
• The AUMCC provides backup services for the nodal MCC capabilities of the USMCC.
• The Canadian MCC (CMCC) provides backup support for the distribution of data to the
USA RCCs and SPOCs.
This ensures that all of the functions of the USMCC are supported, without overloading the
AUMCC and without requiring the AUMCC to support a lot of long-distance communications
links.
D.1.4.2
Non-Nodal MCC Backup
The national MCCs that are not nodal MCCs all have an agreement in place with another MCC to
provide backup support in the event of a failure of their MCC system. Each of these backup
arrangements is identified in the entry for the MCC in section 5.3 “Description of Cospas-Sarsat
MCCs”) of the Data Distribution Plan (document C/S A.001) and they are all listed in Table .

D-5

Table D-1: MCC Backup Agreements
The backup agreements that are in place, as identified in the DDP, are all listed in this table.
Ground Segment
Operator
MCC
Internal Backup
External
Backup
Comments
UAE
AEMCC
SPMCC
Nodal MCC for SCDDR
Algeria
ALMCC
SPMCC
Nodal MCC for SCDDR
Argentina
ARMCC
CHMCC
South Africa
ASMCC
AUMCC
Nodal MCC for SWPDDR
Australia
AUMCC
USMCC
Nodal MCC
Brazil
BRMCC
Yes
USMCC
Nodal MCC for WDDR
Canada
CMCC
Belleville, Ontario
USMCC
Nodal MCC for the WDDR
Chile
CHMCC
USMCC
Nodal MCC for WDDR
China (P.R. of)
CNMCC
HKMCC
Russian Federation
CMC
FMCC
Nodal MCC
Cyprus
CYMCC
ITMCC
France
FMCC
SPMCC
Nodal MCC
Greece
GRMCC
ITMCC
Hong Kong (China)
HKMCC
Yes
TAMCC
Indonesia
IDMCC
SIMCC
India
INMCC
CMC
Nodal MCC for EDDR
Italy
ITMCC
FMCC
Nodal MCC for CDDR
Japan
JAMCC
USMCC
Nodal MCC
South Korea
KOMCC
JAMCC
Nodal MCC for NWPDDR
Malaysia
MYMCC
[AUMCC]
[Nodal MCC for SWPDDR]
Nigeria
NIMCC
[SPMCC]
CNO - SPOC of SPMCC
Norway
NMCC
UKMCC
Pakistan
PAMCC
CMC
Nodal MCC for EDDR
Peru
PEMCC
ARMCC
Qatar
QAMCC
SPMCC
Nodal MCC for SCDDR
Saudi Arabia
SAMCC
SPMCC
Nodal MCC for SCDDR
Singapore
SIMCC
THMCC
Spain
SPMCC
FMCC
Nodal MCC
ITDC (Chinese Taipei)
TAMCC
HKMCC
Togo
TGMCC
[SPMCC]
[Nodal MCC for SCDDR]
Thailand
THMCC
SIMCC
Türkiye
TRMCC
Yes
ITMCC
United Kingdom
UKMCC
Yes
NMCC
USA
USMCC
Wallops Island,
Virginia
AUMCC
and
CMCC
AUMCC provides nodal
backup
CMCC provides local
backup
Vietnam
VNMCC
HKMCC
HKMCC

D-6

D.1.5 Summary of Actions for MCC Scheduled and Contingency/Operational Backup
The following table summarizes actions that should be performed by involved MCCs (Responsible
and Backup) before, during and after a backup period.
Table D-2: MCC Backup Actions
Summary of Actions
Responsible MCC
Backup MCC
Scheduled
Backup
 Suggested 1 – 2 weeks in advance, notify
the scheduled activities and request
backup service from the backup MCC (by
SIT 915 or email) to begin the necessary
coordination.
 Suggested 1 – 2 weeks in advance, and
once the backup period has been agreed,
notify SPOCs in its service area (if any)
the scheduled outage.
 Notify all MCCs in advance (SIT 605)
 Repeat notification to all MCCs (SIT
605) and SPOCs 24 hours prior to the
scheduled activity.
_________________________________
 At the agreed time, stop data distribution,
at least to the nodal MCC and SPOCs.
 If more time than previously requested is
necessary, notify the backup MCC (by
phone) of the backup period extension.
_________________________________
 Once
the
scheduled
activities
are
completed, request end of backup BY
PHONE.
 Start data distribution.
 Notify end of backup to all MCCs (SIT
605) and SPOCs.
 Communications test on primary link is
recommended if backup longer than 6
hours.
_________________________________
 Five minutes before the backup start time,
confirm backup readiness BY PHONE.
 At the start time, implement the backup
configuration changes.
 Notify SPOCs (if any) in the service area
of the failed MCC (e.g., SIT 915).
_________________________________
 Remove the backup configuration after
receiving phone call.
 Notify end of backup to all MCCs (SIT
605).

D-7

Summary of Actions
Responsible MCC
Backup MCC
Contingency
Backup
 Notify the failure and request the backup
less than 1 hour after the issue is
observed.
 If still running, stop data distribution, at
least to nodal MCC and SPOCs.
_________________________________
 Once the failure has been fixed, request
end of backup BY PHONE.
 Start data distribution.
 Notify end of backup to all MCCs (SIT
605) and SPOCS.
 Communication test on primary link is
recommended if backup longer than 6
hours.
 Implement the backup configuration
changes immediately.
 Notify backup to all MCCs (SIT 605).
 Notify SPOCs (if any) in the service area
of the failed MCC (e.g., SIT 915).
_________________________________
 Remove the backup configuration after
receiving phone call.
 Notify end of backup to all MCCs (SIT
605).
Other appropriate actions, different than those indicated in the table above, could be agreed
bilaterally between the Responsible and Backup MCCs.
D.2
LUT Data to Non-parent MCC
There are some occasions when a LUT may have to send data to an MCC that is not operated by
the same Ground Segment Provider as the LUT.
For the case of New Zealand and Australia, where the Australian Maritime Safety Authority
(AMSA) has agreed that the AUMCC will provide MCC services to the New Zealand RCC,
including support of the New Zealand LUTs. This arrangement is made under a bilateral agreement
between the governments of Australia and New Zealand.
Most other cases that require a LUT to send data to an MCC that is not associated with the LUT
(that is, not operated by the same Ground Segment Provider) are the result of backup arrangements.
Again, a bilateral agreement between the LUT operator and the operator of the backup MCC is
required to document the arrangement.
For any such arrangement to work successfully, the following are required:
• An operational LUT and MCC,
• An operational communications link to connect them.
A formal agreement between the operators of the LUT and the MCC, which defines:
• The circumstances under which the LUT will deliver data to the foreign MCC,
• The communications link between the LUT and the MCC,

D-8

• The data that the MCC will provide to the LUT (such as orbit and calibration data),
• The data that the MCC will distribute to the Cospas-Sarsat Ground Segment,
• How the MCC will distribute the data to the Cospas-Sarsat Ground Segment,
• How the MCC will deal with data for the SAR Region of Responsibility of the country that
operates the LUT,
• Contact information for all parties to the agreement.
With these arrangements, the LUT and MCC should be able to operate in the same manner as a
national LUT and MCC operated by one Ground Segment Provider.
D.3
Use of Email for Transfer of SIT Messages
Electronic mail (email or email) is listed in document C/S A.002, “Cospas-Sarsat Mission Control
Centres Standard Interface Description” (the SID), as an optional mode of communications
between an MCC and its destination facilities, to be used by agreement on a bilateral contingency
basis. Guidance on the use of email in the Cospas-Sarsat data distribution network is provided in
Annex I (“Protocol for The Transmission of Sit Messages Via Electronic Mail (Email)”), to the
SID.
In addition to the uses that are formally permitted (by bilateral agreement) between MCCs, email
is also used regularly by MCCs for informal communications with other MCCs or with other
correspondents. This usage is informal and is not regulated by Cospas-Sarsat.
Email is frequently used by MCCs to request or to confirm backup support from other MCCs,
when the normal means of communications may not be available. It may also be used in place of
voice or facsimile communications with other MCCs or with RCCs and SPOCs.
D.4
Re-routing Alert Data between MCCs
Section 3.8 (“Re-routing of Messages”) of the MCC specification (document C/S A.005) allows
that an MCC may provide an alternate path to re-route messages between two MCCs when the
direct link between them fails. This section describes the requirements for the implementation of
this capability.
Essentially, this requires an agreement among all of the participants involved and is intended to
ensure that the use of this re-routing capability has virtually no impact on any other part of the
Cospas-Sarsat Ground Segment.
D.5
Special Procedures for the Transitional Phase-only
The Cospas-Sarsat System is constantly in flux, as new technologies become available and are
incorporated into the System. To maintain such a large system, spread over more than forty
different countries, requires careful management of the introduction of new features into the
system.

D-9

When the new features are relatively small, the impact is low and can be managed by some
relatively straightforward coordination among the Participants. However, for larger changes that
affect many different parts of the system, more extensive coordination is required.
There are several major changes in progress as this Handbook is being prepared (in 2023), and
each of them requires special consideration in the procedures that are specified for the Cospas-
Sarsat Ground Segment:
• The consolidation of the MEOSAR system,
• The introduction of Second-Generation distress beacons,
• The consolidation of the Return Link Service by the Galileo Global Navigation Satellite
System (GNSS),
• The implementation of the Global Aeronautical Distress and Safety System (GADSS) by
ICAO.
These changes have a strong impact on the specifications for the MCCs, as described in several
places in this Handbook.
Because of the magnitude of these changes, it is not realistic to expect that all MCCs will be able
to make any one of these changes at the same time. They will have to be phased in, and during this
phase-in period there will be some MCCs that have not changed and other MCCs that have been
upgraded to support the new service. The Cospas-Sarsat System documents are being revised to
incorporate all of the changes required by these enhancements. These specifications of the Cospas-
Sarsat Ground Segment include provision for each of these phase-in periods.
The majority of the provisions for the introduction of these new capabilities into the Cospas-Sarsat
Ground segment are contained in document C/S A.001 (Data Distribution Plan) and C.S A.003,
“Cospas-Sarsat System Monitoring and Reporting”. Document C/S A.002 (Standard Interface
Description) already includes the existing message formats, and it has been upgraded to include
the descriptions of all of the new messages, so there is negligible impact on that document.
Document C/S A.005, “MCC Performance Specification and Design Guidelines”, has a few
references to the MEOSAR system, but they generally address the generation of specific
MEOSAR messages. If those requirements are not implemented, they will have little effect on the
rest of the Ground Segment. And document C/S A.006 (MCC Commissioning Standard) is only
used when a new MCC is being commissioned, so the changes will not affect any operational MCC
until it is upgraded.
The Cospas-Sarsat Council agreed (at the CSC-62/OPN meeting) to a list of specific upgrades that
are required in each unit of Ground Segment Equipment (GSE) to met various levels of capability,
and the times when these various requirements must be applied. (See Annex 17 of the Summary
Record: CSC-62/OPN/SR/Annex 17.)
The management of the implementation of these specific changes is addressed in the following
sections. As new innovations are introduced into the Cospas-Sarsat System in the future, similar
management procedures are expected to apply.

D-10

D.5.1
Encapsulation Procedure
In each of these cases, an MCC that has been upgraded and is capable of handling the new data
formats and contents is required to support the capability to format the data into a SIT 185 message
(the format that it would normally use to send the data to a SPOC) and to encapsulate the text of
that message into a narrative message (SIT 915; see section B.7.1 of this Handbook).
The narrative message is sent to the destination MCC. Depending on the next destination of the
data:
• If the data is to be forwarded to another MCC, the entire message can be forwarded.
• If the data is to be forwarded to a SPOC or an RCC, the SIT 185 message can be extracted
from the narrative message and sent on.
To allow for continuing operation as each MCC is upgraded to support the new System capability,
the determination of which capability each destination MCC can support is required to be
configurable in the MCC that is building the message.
This procedure requires a small upgrade to every MCC (whether it supports the new capability of
the System) to process these messages, but those changes were deemed to be relatively minor and
were deemed acceptable by the Council.
D.5.2
Distribution of MEOSAR Alerts to LG MCCs
The introduction of the MEOSAR system brings a whole new set of independent location
solutions, with different data contents and characteristics, and requires a new set of SIT message
formats (as listed in Table  in this Handbook). Every MCC must be updated to support the
preparation, transmission, reception, and processing of these new messages. This gives rise to two
classes of MCCs:
• An LG-MCC can support only the old LEOSAR and GEOSAR message formats.
• An LGM-MCC can support both the old LEOSAR and GEOSAR message formats and the
new MEOSAR message formats.
The DDP describes the procedure for the interim period, while both types of MCCs are in use, in
section 3.7.5 (“Distribution of MEOSAR Alerts to MCCs that Are Only LEOSAR/GEOSAR-
Capable”).
The procedure that is specified in this section is to encapsulate any alert message for MEOSAR
data (which would otherwise require a format that cannot be processed by an FG-MCC) as a
SIT 185 format in a SIT 915 narrative message (see section D.5.1 of this Handbook).
The tables in section 5.1 (“SID Implementation Status”) of the DDP (document C/S A.001)
provide information about the current implementation status of message transmission and
reception capability of each MCC in the Cospas-Sarsat Ground Segment.

D-11

D.5.3
Distribution of Second-Generation Beacon Alerts to FGB-Only MCCs
The introduction of Second-Generation distress Beacons (SGBs) brings a whole new set of beacon
messages, with different data contents and characteristics, and requires a new set of SIT message
formats (as listed in Table , Table , and Table  in this Handbook). Every MCC must be updated to
support the preparation, transmission, reception, and processing of these new messages. This gives
rise to two classes of MCCs:
• An FGB-Only MCC can support only the old First-Generation Beacon message formats.
• An SGB-MCC can support both the old First-Generation Beacon and the new Second-
Generation Beacon message formats.
The DDP describes the procedure for the interim period, while both types of MCCs are in use, in
section 3.7.6 (“Distribution of Second-Generation-Beacon (SGB) Alerts to MCCs that Are Only
First-Generation-Beacon (FGB)-Capable”).
The procedure that is specified in this section is to encapsulate any alert message containing SGB
data (which would otherwise require a format that cannot be processed by an FGB-Only MCC) as
a SIT 185 format in a SIT 915 narrative message (see section D.5.1 of this Handbook).
The tables in section 5.1 (“SID Implementation Status”) of the DDP (document C/S A.001)
provide information about the current implementation status of message transmission and
reception capability of each MCC in the Cospas-Sarsat Ground Segment.
D.5.4
Distribution of FGB-ELT(DT) Alerts to Non-FGB-ELT(DT) MCCs
As noted in section 2.2.1.1, the International Civil Aviation Organization (ICAO) has developed
the Global Aviation Distress and Safety System (GADSS), and the Cospas-Sarsat Programme is
developing the Distress Tracking ELT – the ELT(DT) – in support of that initiative. The
introduction of the ELT(DT) requires the support of some new beacon messages, incident alert
messages, and data distribution procedures. These are addressed in section A.4.7.3 of this
Handbook. The processing of the ELT(DT) beacons requires some new SIT message formats (as
identified in Table , and Table  in ANNEX B of this Handbook). Every MCC must be updated to
support the preparation, transmission, reception, and processing of alerts from these new beacons.
At the current time, this MCC enhancement is only a concern for FGBs. SGBs will also support
these beacons, but this support is included in the SGB enhancements discussed in section D.5.3 of
this Handbook. This gives rise to two classes of MCCs:
• An FGB-ELT(DT)-capable MCC can support First-Generation ELT(DT) Beacons.
• A non-FGB-ELT(DT)-capable MCC cannot support First-Generation ELT(DT) Beacons.
The DDP describes the procedure for the interim period, while both types of MCCs are in use, in
section 3.7.8 (“Distribution of FGB-ELT(DT) Alerts to MCCs that Are Not FGB-ELT(DT)-
Capable”).
The procedure that is specified in this section is to encapsulate any alert message for an ELT(DT)
beacon (which would otherwise require a format that cannot be processed by a non-FGB-

D-12

ELT(DT)-capable MCC) as a SIT 185 format in a SIT 915 narrative message (see section D.5.1 of
this Handbook).
The tables in section 5.1 (“SID Implementation Status”) of the DDP (document C/S A.001)
provide information about the current implementation status of message transmission and
reception capability of each MCC in the Cospas-Sarsat Ground Segment.
D.5.5
Distribution of Alerts for RLS-Capable FGBs to Non-FGB-RLS MCCs
The introduction of the Return Link Service (RLS) for distress beacons (initially by Galileo but
expected from other GNSS providers in the near future) requires the support of some new beacon
messages, incident alert messages, and data distribution procedures. These are addressed by the
procedures described in section A.4.7.2 of this Handbook and the new SIT message formats
identified in Table , and Table  of this Handbook. Every MCC must be updated to support the
preparation, transmission, reception, and processing of alerts from these new beacons. At the
current time, this MCC enhancement is more of concern for FGBs; SGBs will also support these
beacons, but this support is included in the SGB enhancements discussed in section D.5.3 of this
Handbook.
In any case, this gives rise to two classes of MCCs:
• An FGB-RLS-capable MCC can support First-Generation Beacons with RLS capability.
• A non-FGB-RLS-capable MCC cannot support First-Generation Beacons with RLS
capability.
The DDP describes the procedure for the interim period, while both types of MCCs are in use, in
section 3.7.7 (“Distribution of Alerts for RLS-Capable FGBs to MCCs that Are Not FGB-RLS-
Capable”).
The procedure that is specified in this section is to encapsulate any alert message for an RLS-
capable FGB beacon (which would otherwise require a format that cannot be processed by a non-
FGB-RLS-capable MCC) as a SIT 185 format in a SIT 915 narrative message (see section D.5.1
of this Handbook).
The tables in section 5.1 (“SID Implementation Status”) of the DDP (document C/S A.001)
provide information about the current implementation status of message transmission and
reception capability of each MCC in the Cospas-Sarsat Ground Segment.
D.5.6
Distribution of RLSP Notifications
The introduction of the RLS has brought another complication to the MCC processing of beacon
messages. As explained section A.4.7.2 of this Handbook, the destination MCC (that is, the MCC
that sends the incident alert message to the responsible SAR authority) also sends the notification
message to the MCC that supports the Return Link Service Provider for the RLS-capable GNSS.

D-13

As above, this gives rise to two classes of MCCs:
• An FGB-RLS-capable MCC can support First-Generation Beacons with RLS capability.
• A non-FGB-RLS-capable MCC cannot support First-Generation Beacons with RLS
capability.
The DDP describes the procedure for the interim period, while both types of MCCs are in use, in
section 3.7.9 (“Distribution of Notifications for RLS-Capable FGB Alerts to the RLSP on Behalf
of MCCs that Are Not FGB-RLS-Capable”).
The procedure that is specified in this section is that every FGB-RLS-capable MCC that receives
an RLS alert with a confirmed position sends the notification message to the MCC that supports
the RLSP. This will result in more redundant messages going to the RLSP, but it will reduce the
chance that an RLS beacon activation will not have the Type-1 Acknowledgement sent to the
beacon.
The tables in section 5.1 (“SID Implementation Status”) of the DDP (document C/S A.001)
provide information about the current implementation status of message transmission and
reception capability of each MCC in the Cospas-Sarsat Ground Segment.
D.5.7
Operational Distribution of Alert Data for SGBs and FGB ELT(DT)s
The DDP describes the interim procedure for the period before SGBs and FGB ELT(DT)s are
approved by Council for operational use. In both cases, the MCCs that are capable of processing
the subject beacons must have the capability to filter the data from the subject beacons, and they
must have this capability configured to filter (that is, suppress) data from the beacons from
operational distribution. In effect, the data is not to be distributed until Council approves the
subject beacons for operational use.
- END OF ANNEX D -

E-1

ANNEX E: SPECIALIZED REQUIREMENTS
E.1
Nodal MCC
As explained in section 4.3 of this Handbook, a nodal MCC is the focal point for Cospas-Sarsat
activities in each Data Distribution Region (DDR).
E.1.1
Requirements
A nodal MCC is a fully operational Mission Control Centre, which performs all of the functions,
identified in section 4.1 of this Handbook, that are required of every MCC in the Cospas-Sarsat
data distribution system.
E.1.2
Operations
In addition to the services that it provides as an operational MCC, a nodal MCC has many other
responsibilities. As the leader of the Cospas-Sarsat Ground Segment operations in the Data
Distribution Region (DDR), it must be able to:
• Support multiple simultaneous communications activities,
• Maintain a complete GEOSORT, so that all incident alert data that it receives, regardless
of the DDR to which it belongs, will be sent to the correct MCC or other alert destination,
• Validate and forward all system data that it originates or that it receives from another MCC,
• Route narrative information messages to the correct destination,
• Receive and process the Cospas-Sarsat Quality Management System (QMS) data for all
components of the Ground Segment that are within its DDR (as described in section 4.6 of
this Handbook),
• Coordinate all of the activities necessary to support the functioning of the Cospas-Sarsat
System within its DDR, including:
-
The commissioning (or re-commissioning) of an MCC,
-
The backup plans for all MCCs,
-
The backup tests of all MCCs,
-
Other test activities as determined by the Cospas-Sarsat Council.
• Make the decision to declare a component of the Cospas-Sarsat Ground Segment as
Commissioned not Operational (CNO), as appropriate.
The staff at the nodal MCC must, at all times, be capable of performing any activities that may be
necessary to support these functions.

E-2

Because of the key role of the nodal MCC, its back-up plan must include provision for the support
of all operations, including the nodal functions, if it were to go out of service.
E.2
Reference Beacon Provider
As specified in various Cospas-Sarsat documents, and as explained in section A.4.7.4 of 0 of this
Handbook, the Cospas-Sarsat System requires that various types of reference beacons be available
to support the operations of the System. These beacons are operated by the Participants in the
Programme; the Participant who provides a reference beacon accepts certain obligations to the
Programme and to the other Participants.
The functions that are required of a reference beacon provider include:
• Supplying the beacon and any related equipment necessary for its operation,
• Maintaining the beacon and keeping it in operation according to the declared schedule,
• Identifying and designating an MCC as an operational point of contact for communications
regarding this beacon,
• Notifying all Participants that the beacon is available, and providing the necessary
information about it:
-
The precise location data for the beacon,
-
The exact transmit frequency,
-
The exact schedule for the operation of the beacon,
• Providing information about the beacon to the Cospas-Sarsat Secretariat, so that they can
maintain the Detailed Beacon Types page on the Cospas-Sarsat professional website,
• Notifying other Participants when the beacon is not functioning as planned.
To find out more about the available reference beacons, go to the Cospas-Sarsat professional
website and select the <BEACON> tab, then <DETAILED BEACON TYPES> and the <REFERENCE
BEACONS> or <ORBITOGRAPHY BEACONS> tab.
Because of the use of these reference beacons, the information that is provided must be very
accurate:
• Location data accurate to at least 0.01 seconds of latitude and longitude in the Bureau
International de l'Heure (BIH) Geodetic Reference System (for example, referenced to the
WGS84 standard ellipse. This allows an error of approximately 3 metres, depending on the
latitude; an extra digit of accuracy is even better.
• Frequency data should be to 1 Hz or better.
• The schedule should specify the times of activation to within one second or better.
For those beacons, such as the orbitography reference beacons, which are essential to the operation
of the System, the beacon provider is required to provide the assurance that the beacon will be

E-3

maintained and kept active at all times. For other reference beacons, it is sufficient that the beacon
be operated to the specified parameters by the best effort of the beacon provider.
E.3
Beacon Registry
Every country that participates in the International Maritime Organization (IMO) or the
International Civil Aviation Organization (ICAO) is required, by the terms of their participation
in those organizations, to maintain a registry of all distress beacons that are identified with their
country code in the beacon message. The Cospas-Sarsat MCC that serves the area that includes
the country must have access to the national beacon database registry and must support requests
for the registration data from any other MCC.
This support includes the ability to respond to requests, from the responsible authorities, for
information about any beacon with a country code in the MCC Service Area. As each request is
received, the MCC must forward the request for information to the appropriate national beacon
registry and must return the information retrieved to the requesting authority.
Each national beacon registry is organized according to national requirements. In some countries,
the registry is divided into several parts, operated by different agencies according to the needs of
the national administration. For example, in some countries, the beacon registry for EPIRBs is a
part of a larger marine database of shipping, while the beacon registry for ELTs is contained in an
aviation database. In such a case, the registration of PLBs requires a separate database.
For any country that does not maintain its own beacon registry (or does not have a place to register
a particular type of distress beacon), the Cospas-Sarsat Programme maintains the International
Beacon Registry Database (IBRD), which will manage the registration records for that country.
Depending on the request of the country, the IBRD may include all beacons registered with that
countries code, or it may only include of beacons of a specified type. Access to the IBRD is
available, on request, to all Cospas-Sarsat MCCs and to all authorized SAR authorities. The IBRD
is specified and described in the System documents that are listed in Table 2-7, in section 2.4.5 of
this Handbook.
E.4
Space Segment Provider
The International Cospas-Sarsat Programme Agreement (the ICSPA, document C/S P.001) was
originally written with the idea that the Space Segment would be provided by the Parties to the
Agreement, and that any other nation that wised to contribute to the Space Segment would accede
to the ICSPA and become a Party to the Agreement. However, there have since been several
instances where a country or an organization has offered to become a Space Segment Provider
without acceding to the ICSPA.
The Council, acting under the provisions of Article 9(i) of the ICSPA (giving it the function of
“taking decisions upon matters of joint relations with States non-Parties to this Agreement, as well
as international organizations”), has entered into specific individual agreements with these
countries and organizations to enable them to become Space Segment Providers in the Cospas-
Sarsat System.

E-4

The current Space Segment Providers are listed in Table 3-2. Table  identifies the agreements that
define the terms under which non-Party Participants provide the Space Segment components listed
in Table 2-1. These agreements are available on the Cospas-Sarsat website (under Documents,
select <SYSTEM DOCUMENTS> and then <DOCUMENT TYPE> and <C/S P.000 SERIES -
PROGRAMME>).
Table E-1: Space Segment Providers and Contributors to the Space Segment
Space
Segment
Providers
and
Contributors
Document
Number
Component
Satellite
Space Segment Contribution
Canada
C/S P.001
Sarsat
LEOSAR
SARR instruments
Canada
C/S P.001
SAR/GPS
MEOSAR
SARR instruments
EUMETSAT
C/S P.008
METEOSAT
GEOSAR
Satellite platform and all SAR instruments
European
Commission
C/S P.017
SAR/Galileo
MEOSAR
Satellite platform and all SAR instruments
France
C/S P.001
SARP instruments
European
Commission
(Galileo Joint
Undertaking1)
C/S P.014
SAR/Galileo
MEOSAR
Satellite platform and all SAR instruments
India
C/S P.009
Insat
GEOSAR
Satellite platform and all SAR instruments
Russian
Federation2
C/S P.001
Cospas
LEOSAR
Satellite platform and all SAR instruments
Russian
Federation2
C/S P.001
Glonass
MEOSAR
Satellite platform and all SAR instruments
Russian
Federation2
C/S P.001
Electro-L
GEOSAR
Satellite platform and all SAR instruments
Russian
Federation2
C/S P.001
Louch
GEOSAR
Satellite platform and all SAR instruments
USA
C/S P.001
Sarsat
LEOSAR
Satellite platform
USA
C/S P.001
DASS
MEOSAR
Satellite platform and all SAR instruments
USA
C/S P.001
SAR/GPS
MEOSAR
Satellite platform

E-5

Space
Segment
Providers
and
Contributors
Document
Number
Component
Satellite
Space Segment Contribution
USA
C/S P.001
GOES
GEOSAR
Satellite platform and all SAR instruments
Notes to Table :

The Galileo Joint Undertaking has been replaced by the European GNSS Supervisory
Authority, which has since become the European Global Navigation Satellite Systems Agency (the
European GNSS Agency, or GSA) as the party to this agreement and as the SAR/Galileo Space
Segment Provider.

The Union of Soviet Socialist Republics (USSR) was a Party to the original ICSPA, and
the ICSPA was signed by representatives of the USSR and ratified by the USSR. In 1992, after the
breakup of the USSR, the Russian Federation agreed to take the palace of the USSR as a Party to
the ICSPA and as the Space Segment Provider for the COSPAS, SAR/Glonass, Electro-L and
Louch spacecraft.
Any other Government or Organization that wishes to become a Space Segment Provider should
approach the Cospas-Sarsat Council (through the Party representatives, listed in document
C/S P.010, or through the Secretariat).
E.5
Return Link Service Provider
The Return Link Service (RLS) is a service that provides the user with the ability to send short
messages through the navigation downlink signals of a Global Navigation Satellite System
(GNSS) to an identified receiver. For the Cospas-Sarsat System, the intended function is to send
an Acknowledgement message to a receiver in the distress beacon that initiated an incident alert
message. This facility is introduced in section 4.4.2.4 of this Handbook and is further discussed
and explained in section A.4.7.2 of this Handbook.
At the present time (in 2023), the only GNSS that operates an RLS capability is the European
Commission’s Galileo GNSS, which is used in the SAR/Galileo MEOSAR system. The Chinese
Beidou GNSS and Russian Glonass GNSS are both planning to offer this service, but neither of
those RLS services is available yet.
The RLS system has been proposed for various uses in relation to the Cospas-Sarsat System:
•
Type 1 Acknowledgement
Acknowledge that the beacon message has been
detected by the Cospas-Sarsat System,
•
Type 2 Acknowledgement
Acknowledge that the beacon message has been
received by the RCC that will organize the Search and
Rescue efforts,

E-6

•
Remote Beacon Activation
Turn the beacon on to start transmitting its distress
message,
•
Beacon Cancellation
Have the beacon transmit the correct sequence of
cancellation messages and then stop transmitting.
The only RLS service that is currently supported by the Cospas-Sarsat System is the Type-1
Acknowledgement.
E.5.1
SAR/Galileo RLS
More information about the RLS is available in the SAR Galileo Enhanced Service Definition
Document (SAR SDD), published by the European Commission (EC). That document is available
on the European GNSS Service Centre website at https://www.gsc-europa.eu/electronic-
library/programme-reference-documents\#Galileo%20pub: Select <GALILEO> <SEARCH AND
RESCUE SERVICE> and then click on <GALILEO - SEARCH AND RESCUE - SERVICE DEFINITION
DOCUMENT (SAR SDD V2.0)> to download the document (in PDS format).
- END OF ANNEX E -

F-1

ANNEX F: MONITORING AND TEST ACTIVITIES
F.1
Commissioning Support
As a part of its role as the coordinator of all Cospas-Sarsat activities for the Ground Segment
Provider that operates the MCC, an MCC must be prepared to support the commissioning and
testing of the various components of the Cospas-Sarsat System, as they are established, operated,
and maintained by the administration that operates the MCC.
These commissioning and test activities are described in the following sections of this ANNEX F
of this Handbook.
F.1.1
MCC Commissioning
The commissioning of an MCC is the responsibility of the Ground Segment Provider
administration that will provide and operate the MCC. The details of the requirements for the
commissioning of a Cospas-Sarsat MCC are described in the MCC documents:
• C/S A.005:
MCC Performance specification and Design Guidelines,
• C/S A.006:
MCC Commissioning Standard,
And in the other operational documents:
• C/S A.001:
Cospas-Sarsat Data Distribution Plan,
• C/S A.002:
Cospas-Sarsat Standard Interface Description,
• C/S A.003:
Cospas-Sarsat System Monitoring and Reporting.
As described in the commissioning standard, the MCC will have to coordinate the activities that
are required in support of the commissioning, including such things as:
• Identifying the host MCC (HMCC) that will support the commissioning of the new MCC
under development (DMCC),
• Determining the MCC Service Area that will be supported by the new MCC,
• Meeting with the HMCC and preparing the DMCC Commissioning Test Plan,
• Coordinating with the HMCC to:
-
Notify other Ground Segment Providers of the commissioning activities and schedule,
-
Notify other Cospas-Sarsat Participants of the test beacons that will be activated in
support of the commissioning,
• Performing all of the necessary pre-integration test activities, as agreed with the HMCC,

F-2

• Setting its configuration to ensure that data from the DMCC will not be distributed to other
MCCs except as agreed in the Commissioning Test Plan,
• Collecting data, as necessary, in support of the DMCC Commissioning Report,
• Preparing the draft DMCC Commissioning Report, and submitting it to the HMCC for
completion,
• Coordinating with the HMCC to determine when the new MCC is ready to be declared at
Interim Operational Capability (IOC),
• Setting its configuration to support the distribution of data during the MCC’s IOC phase,
• Monitoring the operations of the MCC during the IOC phase of operations,
• Coordinating with the HMCC to determine when the new MCC is ready to be declared at
Full Operational Capability (FOC),
• Notifying the other Ground Segment Providers when the MCC is declared at FOC.
Once the new MCC is fully operational, the MCC accepts the responsibility to participate fully in
the Cospas-Sarsat Ground Segment, as described in documents C/S A.005 (MCC Performance
Specification and Design Guidelines) and C/S A.003, “Cospas-Sarsat System Monitoring and
Reporting”.
When the equipment in a commissioned MCC is upgraded or replaced, the new equipment may
have to be partially or completely re-commissioned, depending on the nature of the changes to the
MCC. During that re-commissioning, the upgraded MCC will have to provide a similar level of
support as it would when a new MCC is commissioned. At the same time, it will have to continue
to perform all of the services that it provides as an operational MCC. In most cases, this will require
the parallel operation of the original MCC equipment and the new equipment under test until the
re-commissioning of the MCC has been successfully completed.
As a participant in the annual meeting of the Cospas-Sarsat Joint Committee (JC), the MCC
manager will be expected to coordinate preparation and presentation of the commissioning report
for their own MCC. They will also be expected to coordinate the review of other MCC
commissioning reports within the administration that they represent, and to present the results of
that review at the JC meeting.
F.1.2
LUT Commissioning
The commissioning of a LUT is the responsibility of the Ground Segment Provider administration
that will provide and operate the LUT. The details of the requirements for the commissioning of a
Cospas-Sarsat LUT are described in the documents that are listed in Table .

F-3

Table F-1: LUT Commissioning Documents
Document
Number
Title
T.005
LEOLUT Commissioning Standard
T.010
GEOLUT Commissioning Standard
T.020
MEOLUT Commissioning Standard
The MCC that is operated by the same Ground Segment Provider, and which is associated with
the new LUT, will be expected to coordinate the activities that are required in support of the
commissioning, including such things as:
• Notifying other Ground Segment Providers of the commissioning activities and schedule,
• Notifying other Cospas-Sarsat Participants of the test beacons that will be activated in
support of the commissioning,
• Coordinating these activities with other MCCs,
• Setting its configuration to ensure that data from the LUT under test will not be distributed
to other MCCs until the LUT has passed the commissioning tests,
• Providing data, as necessary, in support of the LUT Commissioning Report,
• Reviewing the LUT Commissioning Report,
• Confirming that the LUT has passed the commissioning tests and is ready to be declared
at Interim Operational Capability (IOC),
• Setting its configuration to support the distribution of data from the new LUT to the rest of
the Cospas-Sarsat Ground Segment when the LUT achieves IOC and FOC,
• Notifying the other Ground Segment Providers when the LUT is declared at IOC,
• Monitoring the operations of the LUT during the IOC phase of operations,
• coordinating the submission of the LUT Commissioning Report to the Cospas-Sarsat
Secretariat for review by the Cospas-Sarsat Joint Committee (or alternate meeting, as
determined by Council),
• Confirming that the LUT has successfully operated during its IOC phase and is ready to be
declared at Full Operational Capability (FOC),
• Notifying the other Ground Segment Providers when the LUT is declared at FOC.
Once the new LUT is fully operational, the MCC accepts the responsibility to monitor the
operations of the LUT, as described in document C/S A.005 (MCC Performance Specification and
Design Guidelines) and the document C/S A.003, “Cospas-Sarsat System Monitoring and
Reporting”.
When a commissioned LUT is upgraded or replaced, the new equipment may have to be re-
commissioned, depending on the nature of the changes to the LUT. During that re-commissioning,

F-4

the associated MCC will have to provide a similar level of support to the modified LUT as it would
for a new LUT.
As a participant in the annual meeting of the Cospas-Sarsat Joint Committee (JC), the MCC
manager will be expected to coordinate preparation and presentation of the commissioning report
for any LUT that is operated by their administration. They will also be expected to coordinate the
review of other LUT commissioning reports within the administration that they represent, and to
present the results of that review at the JC meeting.
F.1.2.1
Notifying a LUT to ITU
Although it is not a part of the commissioning of a LUT, the LUT commissioning standards all
state that “Administrations should register their [LUT’s] use of the 1544.5 MHz frequency band
by notifying their [LUTs] with the International Telecommunication Union (ITU) in accordance
with article 11 of the radio regulations.” As a part of its role as coordinator of the national
participation in the Cospas-Sarsat Programme, an MCC should be prepared to assist its
administration with the registration of all associated LUTs.
As indicated in section 2.2.1.3, each LUT commissioning standard includes an Annex H, with a
copy of the form approved by ITU for this notification and a description of how the form should
be filled out for the LUT. In addition, ITU offers, on its web site (at www.itu.int), a link to
download software to generate a form to register an Earth Station and to fill it before sending it to
ITU. The web site also has a document that explains how to use this software tool.
The MCC should ensure that all associated LUTs are notified to ITU. One of the main purposes
of the declaration of LUTs to ITU is to ensure that these LUTs could formally benefit from the
“Protection criteria for the Cospas-Sarsat Users Terminals in the 1544-1545 MHz” (ITU-R
M.1731). When a LUT is officially declared at ITU, any interference matter in the received
frequency of the LUT could be brought to ITU and resolved in accordance with appropriate ITU
procedures. When a LUT has not been declared to ITU this process cannot be used so easily.
F.1.3
Space Segment Commissioning
The Cospas-Sarsat Programme makes use of spacecraft that are contributed by the Parties and
other Space Segment Providers. Because these spacecraft are generally designed for other
purposes, and the Cospas-Sarsat payloads are carried as payloads of opportunity, Cospas-Sarsat is
generally not in a position to specify the requirements for these payloads. Consequently, Cospas-
Sarsat does not commission the spacecraft in the same sense as it does for the Ground Segment
components. That is, the commissioning does not verify that the spacecraft meets a prescribed
specification.
Instead, the commissioning of the Space Segment consists in the measurement and reporting of
the characteristics of each spacecraft after it has been launched and is operating in orbit. The
requirements for the commissioning of a spacecraft are identified in the documents listed in
Table  F-2.

F-5

Table F-2: Spacecraft Commissioning Documents
Document
Number
Title
T.003
Description of the 406-MHz Payloads Used in the Cospas-Sarsat LEOSAR
System
T.004
Cospas-Sarsat LEOSAR Space Segment Commissioning Standard
T.011
Description of the 406 MHz Payloads Used in the Cospas-Sarsat GEOSAR
System
T.013
Cospas-Sarsat GEOSAR Space Segment Commissioning Standard
T.016
Description of the 406 MHz Payloads Used in the Cospas-Sarsat MEOSAR
System
T.017
Cospas-Sarsat MEOSAR Space Segment Commissioning Standard
In general, the commissioning of a spacecraft is performed by the Space Segment Provider that is
responsible for that spacecraft. However, other MCCs may be called on to assist with the
commissioning of a spacecraft:
• If there is a need to activate one or more beacons in support of the commissioning tests, all
MCCs will be notified, and may be asked to send the collected data (or the computed
results) to the commissioning agency.
• If the commissioning agency requires the support of a LUT other than the LUT(s) that it
operates, it may ask another Ground Segment Provider for support of the commissioning.
• Some MCCs may be asked to participate in the distribution of data from the spacecraft that
is being commissioned.
• Until the commissioning is completed, all MCCs may be asked to suppress the distribution
of data from the spacecraft that is being commissioned.
For most of these operations, the MCCs will usually be expected to perform only their normal
operational functions.
The MCC operator may also be expected to support the administration of the Space Segment
Provider in the registration of the new spacecraft with ITU.
As a participant in the annual meeting of the Cospas-Sarsat Joint Committee (JC), the MCC
manager will be expected to coordinate the review of the spacecraft commissioning report within
the administration that they represent, and to present the results of that review at the JC meeting.
F.2
MCC Annual Backup Test
The requirements for the testing of the backup arrangements for an MCC are described in
sections 3.7.2 and 3.7.3 of the DDP (document C/S A.001). The backup arrangements for each
MCC must be agreed in advance and must be recorded in section 5.3 of the DDP.

F-6

Every MCC is required to test its backup procedures annually. This backup test should include
tests of all of the functions listed (in section 5.3 of the DDP) as supported by the backup system.
It should also include a test of each communications link that is used during the backup procedure.
The annual backup test should be planned for a period of six hours or more; the actual time for the
backup test should be agreed bilaterally between the MCC and its backup provider.
The only time when this annual backup test is not required is when the backup procedure has been
successfully exercised for a period of time not less than six hours during the year prior to the
planned annual test.
When an MCC plans a backup test, it is required to notify all MCCs, and all SPOCs that it will
serve during this backup test, of the plans for this backup. (See section 3.6.4 of the DDP.)
F.3
Monthly Communication Link Testing with SPOCs
Each MCC is encouraged to perform a monthly communications test with every SAR Point of
Contact (SPOC) within its Service Area, unless that communications link has been used
successfully in operations during the previous month.
The communications test consists of the transmission of a test message to the SPOC and the receipt
at the MCC of an acknowledgement from the SPOC that the message has been successfully
received at the SPOC. The acknowledgement must be a manual acknowledgement from the
operator of the SPOC, received within thirty minutes of the original transmission; an automatic
acknowledgement by the communications network is not sufficient for a successful test.
The results of these communications tests are to be reported to the Cospas-Sarsat Secretariat. This
information is summarized in the annual status report on system operations, which the Secretariat
prepares and which is reviewed at the next meeting of the Cospas-Sarsat Joint Committee. This
report is also shared with the IMO Sub-Committee on Navigation, Communications and Search
and Rescue (NCSR) as a part of the annual report from the Cospas-Sarsat Secretariat.
F.4
Beacon Type Approval Tests
The use of Cospas-Sarsat distress beacons is regulated by each national administration. All
administrations include a requirement that the design of any distress beacon that is sold and used
operationally must be approved by the Cospas-Sarsat Council. The process for this approval is
specified in document C/S T.007, “Cospas-Sarsat 406 MHz Distress Beacon Type Approval
Standard”.
The testing that is required by C/S T.001 includes, among other tests, a satellite qualitative test
during which the beacon is activated and transmits its messages for an extended period of time.
(This satellite qualitative test is described in section A.2.5 of the Type Approval Standard.) “This
test is to be performed only in coordination with the cognizant Cospas-Sarsat Mission Control
Centre (MCC) and local authorities.” That is, the MCC responsible for the Service Area in which
the test is run must be notified of the test and must approve it.

F-7

The MCC may also be asked to collect and to report on the data that is generated by the beacon
during this test. While the MCC must consider the local Search and Rescue conditions at the time
of the requested test, MCCs are encouraged to support these tests to the best of their ability.
The results of the beacon type-approval tests are reported to the Cospas-Sarsat Council, and they
are reviewed by an Experts Working Group convened by the Council before they are reviewed and
approved by the Council. The type approval report for every beacon that is approved by Council
is available on the Cospas-Sarsat website, under the <BEACONS> tab: select <APPROVED BEACON
MODELS (TACS)> and then select <REPORT> for the desired beacon model.
F.5
Interference Monitoring
In order to protect the Cospas-Sarsat System from being degraded by interference, the Participants
are encouraged (see section 3.12 of document C/S A.005 (MCC Performance Specification and
Design Guidelines) to monitor both of the frequency bands that are allocated for System use, and
to report any unauthorized active transmissions on either of these frequency bands:
• The beacon uplink band between 406.000 MHz and 406.100 MHz,
• The satellite downlink band between 1,544.500 MHz and 1,545.500 MHz.
This monitoring is usually performed by the Cospas-Sarsat LUTs and is reported to the associated
Mission Control Centre.
Although there is no formal requirement to distribute these reports, “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 ITU [International Telecommunication Union] in accordance with their national
procedures and ITU requirements.” (See section 5.4 of document C/S A.003, “Cospas-Sarsat
System Monitoring and Reporting”.
The reporting of interference through national procedures will require some coordination with
national regulatory bodies. These bodies, working with ITU, will make whatever effort is
necessary to stop the interfering transmissions and to restore the frequency band to its authorized
use.
MCCs are also encouraged to notify other Ground Segment Providers in the affected area with
reports of any interference that they detect. This is done by transmitting an interferer alert message
(SIT 121) to all MCCs whose Service Area might be affected by the interferer.
F.5.1
In-Band Interference
ITU regulations, which are enacted into law in all ITU member states, require that no one use a
frequency band except for the authorized purposes. Any transmissions in these bands for purposes
that are not related to distress transmissions for satellite detection and for Search and Rescue
support are not authorized, and should be reported and suppressed.

F-8

F.5.2
Out-Of-Band Interference
In addition to the requirement to detect and suppress interference within the frequency bands that
are reserved for use by the Cospas-Sarsat System, ITU has recognized that, because of the
sensitivity of the System, there should be limitations on transmissions in the frequency bands
adjacent to the 406 MHz uplink band, which may cause out-of-band interference.
In a paper presented to the Cospas-Sarsat Council in 2019 (CSC-61/OPN/Inf.13), the Secretariat
said:
“The ITU’s World Radiocommunication Conference 2015 (WRC-15) recognized that unwanted
emissions from radiocommunication services outside the frequency band 406 to 406.1 MHz also
have a potential to cause interference to space-based MSS receivers within 406 to 406.1 MHz due
to the tight link margins of EPIRBs and the considerable cumulative power flux density that could
be encountered by a space-based receiver from globally-deployed mobile telephone (and other)
stations transmitting in the immediately adjacent bands. Bearing this in mind, WRC-15 decided to
revise Resolution 205 to introduce additional protection measures to be applied in the adjacent
bands 405.9 to 406.0 MHz and 406.1 to 406.2 MHz.”
A circular letter was issued by ITU in December 2018 to implement the revised regulations. This
circular letter included a list of the parameters to be monitored, and the periodicity and duration of
measurements (as defined in document ITU-R SM.1051-41).
MCCs are encouraged to work with their LUT operators to monitor and report on any out-of-band
interference that might affect the Cospas-Sarsat System.
- END OF ANNEX F -

G-1

ANNEX G: COSPAS-SARSAT MODEL COURSE
G.1
Purpose of the Model Course
The purpose of this model courses is to assist Administrations that operate Mission Control Centres
with the development and introduction of MCC Operator training courses. This also includes the
updating and improvement of existing courses so that the quality and effectiveness of training may
be consistent internationally.
It is not the intention of the model course program to present instructors with a rigid “teaching
package” but simply to provide guidelines and pointers to useful resources. As in all training
endeavours, the knowledge, skills and dedication of the instructors are the key components in the
transfer of knowledge and skills to those being trained.
Scope
This course provides an outline of the training required for those who are designated to perform
the duties and responsibilities of an Mission Control Centre operator assigned to a national MCC,
as defined in document C/S A.005, Cospas-Sarsat Mission Control Centre (MCC) Performance
Specification and Design Guidelines.
The purpose of this model course is to assist Administrations in meeting their own training needs,
and the obligations they accepted under the International Cospas-Sarsat Programme Agreement,
document C/S P.001.
G.2
Training Resources
The primary training manual for MCC operators is document C/S G.010, MCC Handbook. This
manual is supported by a video library available on YouTube and Moodle.
Additional manuals and written reference material includes:
Document C/S G.003, Introduction to the Cospas-Sarsat System,
Document C/S G.004 Cospas-Sarsat Glossary,
Document C/S G.007, Handbook on Distress Alert Messages for Rescue Coordination
Centres (RCCs), Search and Rescue Points of Contact (SPOCs) and IMO Ship Security
Competent Authorities,
Document C/S S.007, Handbook of Beacon Regulations,
Document C/S S.011, Cospas-Sarsat Glossary,
The History and Experience of the International Cospas-Sarsat Programme for Satellite-
Aided Search and Rescue.

G-2

Operational documentation describing the operation of an MCC includes:
1.
Document C/S A.001, Data Distribution Plan (DDP),
Document C/S A.002, Cospas-Sarsat Mission Control Centres Standard Interface
Description (SID),
Document C/S A.003, Cospas-Sarsat System Monitoring and Reporting,
Document C/S A.005, Cospas-Sarsat Mission Control Centre (MCC) Performance
Specification and Design Guidelines,
Document C/S A.006, Cospas-Sarsat Mission Control Centre Commissioning Standard.
Videos- available on the Cospas-Sarsat website (hosted on YouTube) and on Moodle
(https://moodle.406.org/):
1.
Videos about the Programme,
Videos and graphics- about owning a beacon,
Training videos and graphics:
a.
RCC Operator Training,
b.
MCC Operator Training.
G.3
Detailed Outline
G.3.1
Concept of the Cospas-Sarsat System:
a.
RCC Operator Training,
b.
Beacon, Space and Ground Segment,
c.
System documents,
d.
System data and statistics.
Training resources:
•
Document C/S G.010, MCC Handbook,
•
Document C/S G.003, Introduction to the Cospas-Sarsat System,
•
Video Playlist: Videos About the Programme,
-
Introduction to the Cospas-Sarsat System,
-
How Cospas-Sarsat Works,
•
Video Playlist: About Owning a Beacon.
G.3.2
Management of the Cospas-Sarsat Programme:
a.
Council, Joint Committee, Task Groups and Experts’ Working Groups meetings,
b.
Programme Agreement and Administrations responsibilities.

G-3

Training resources:
•
The History and Experience of the International Cospas-Sarsat Programme for
Satellite-Aided Search and Rescue (https://www.cospas-sarsat.int/en/documents-
pro/documents/history-and-experience-of-the-programme),
•
Document C/S P.001, International Cospas-Sarsat Programme Agreement,
•
Document C/S G.003, Introduction to the Cospas-Sarsat System,
•
Video Playlist: Videos About the Programme.
G.3.3
Space Segment (LEO, GEO and MEO):
a.
Status of Space Segment,
b.
LEOSAR SARP and SARR,
c.
TCAL,
d.
Satellite manoeuvres,
e.
MEOSAR system operation.
Training resources:
•
Cospas-Sarsat website and webpages related to Space Segment status
(https://www.cospas-sarsat.int/en/pro / SYSTEM Tab),
•
Document C/S G.010, MCC Handbook,
•
Video Playlist: Training Resources.
G.3.4
Ground Segment:
a.
Basic functions of LUTs and MCCs,
b.
Status of the Ground Segment,
c.
MEOLUT Hardware / Technology (i.e., parabolic vs phased array antennas).
Training resources:
•
Cospas-Sarsat website and webpages related to Ground Segment status
(https://www.cospas-sarsat.int/en/pro / SYSTEM Tab),
•
Status of the Ground Segment,
•
Document C/S G.010, MCC Handbook,
•
Video Playlist: Training Resources.
G.3.5
LUTs:
a.
MCC processing of LUT data,
b.
MEOLUT Networking,
c.
Manufacturers’ operational manuals,
d.
Local LUT operator interface,
e.
Monitoring of LUTs,
f.
Orbit and SARP updates,
g.
Communications to and from LUTs,
h.
Alarms and warnings from LUTs,

G-4

i.
Location data concepts and terminology, e.g., Doppler A and B positions, DOA
positions, GNSS positions.
Training resources:
•
Cospas-Sarsat website and webpages related to LUTs (https://www.cospas-
sarsat.int/en/pro / SYSTEM Tab),
•
Document C/S G.010, MCC Handbook,
•
Document C/S T.002, Local User Terminal Performance Specification and Design
Guidelines,
•
Document C/S T.009, GEOLUT Performance Specification and Design
Guidelines,
•
Document C/S T.019, MEOLUT Performance Specification and Design
Guidelines,
•
Video Playlist: Videos About the Programme,
•
Video Playlist: Training Resources.
G.3.6
MCCs:
a.
Functions of an MCC,
b.
Manufacturers’ operational manuals,
c.
Local MCC operator interface,
d.
Monitoring of MCC operation,
e.
Communications to and from MCC,
f.
Alarms and warnings from MCC.
Training resources:
•
Cospas-Sarsat website and webpages related to MCCs (https://www.cospas-
sarsat.int/en/pro / SYSTEM Tab),
•
Document C/S G.010, MCC Handbook,
•
Document C/S A.001, Data Distribution Plan (DDP),
•
Document C/S A.002, Mission Control Centres Standard Interface Description
(SID)
•
Document C/S A.003, Cospas-Sarsat System Monitoring and Reporting,
•
Document C/S A.005, Mission Control Centre (MCC) Performance Specification
and Design Guidelines,
•
Video Playlist: Videos About the Programme,
•
Video Playlist: Training Resources.
G.3.7
Cospas-Sarsat Data Distribution Procedures:
a.
Concept of service areas, DDRs and nodal MCCs,
b.
Concept of RCCs and SPOCs and search and rescue regions,
c.
What to do in case of false alerts,
d.
Matching and merging of locations:
-
Doppler to Doppler matching,

G-5

-
Doppler to encoded matching,
-
Encoded to encoded matching,
-
DOA to DOA,
-
DOA to Doppler,
-
DOA to encoded,
e.
Concept of LEO/GEO/MEO alerts,
f.
MEOSAR average carrier to noise ratio and encoded location error estimate,
g.
MEOSAR TOA, FOA, TDOA and DOA,
h.
Error ellipse and Window Factor,
i.
Data distribution:
-
406 MHz Alert Data Distribution Procedures,
-
Processing Matrices, Message Formats and Distribution of 406 MHz
Alerts,
-
Unlocated, unconfirmed and confirmed alerts,
-
Conflict alerts,
-
Continued transmission,
-
NOCR and SSAS,
-
ELT(DT) and RLS beacons,
j.
Data validation:
-
406 MHz Alert Message Validation,
-
Concept of filtering redundant data and better-quality alerts
-
Based on same beacon event (SBE), poor quality flag indicators, distance
criterion and image position determination,
-
Bit errors and how they are handled,
k.
Annual System level test (SLT).
Training resources:
•
Document C/S G.010, MCC Handbook,
•
Document C/S A.001, Data Distribution Plan (DDP),
•
Document C/S A.002, Mission Control Centres Standard Interface Description
(SID),
•
Document C/S A.003, Cospas-Sarsat System Monitoring and Reporting,
•
Video Playlist: About Owning a Beacon,
•
Video Playlist: Training Resources.
G.3.8
Cospas-Sarsat Message Formats:
a.
International character set,
b.
MCC to MCC message formats and content,
c.
MCC to RCC/SPOCs (SIT 185 formats),
d.
Concept of message fields,
e.
Types of alert messages:
-
Unconfirmed, confirmed, unlocated, encoded, conflict and NOCR,
-
Interferer alerts,
f.
Types of location in SIT 185 messages,

G-6

g.
System information:
-
Orbit vectors, TCAL,
-
SARP calibration,
-
System status,
h.
Narrative messages.
Training resources:
•
Document C/S G.010, MCC Handbook,
•
Document C/S G.007, RCC Handbook,
•
Document C/S A.001, Data Distribution Plan (DDP),
•
Document C/S A.002, Mission Control Centres Standard Interface Description
(SID),
•
Video Playlist: Training Resources,
•
Types of location in SIT 185 messages training resources.
CLASSIFICATION ESTIMATED
ACCURACY
DATA SOURCE
REMARKS
GNSS
Usually 2’’
accuracy
(~100m) (see
remarks)
GNSS
Caution with:
1- the refresh rate (see beacon TAC on C/S
website),
2- protocol used (user location protocol provides
accuracy of 4 min of angle),
3- coarse position only (i.e., PDF-2 is missing)
=> rounded to 15-min angle (e.g., 50° 30’ N
003° 15’E)
DOA
See the value
of
ESTIMATED
ERROR.
MEOSAR
MEOSAR is designed to provide <5km in 95%
of the case after 10 min... depending on whether
the beacon is moving or static
DOPPLER A/B
~10 to 20 km
Single LEOSAR pass
(or 2 passes on the
exact same orbit)
Value around 2 positions until the ambiguity is
resolved.
RESOLVED
DOPPLER
~10 to 20 km
Multiple
LEOSAR
passes
in
different
orbits
Up to 5 km or even 2 km in the best case, may
take some time for the System to derive this
position
MCC
REFERENCE
Unknown,
depending on
the positioning
system used
(DOA,
DOPPLER,
GNSS...)
MCC REFERENCE accuracy is generally a
value close to the accuracy of the DOA and or
Doppler location used by the MCC as its
reference.
G.3.9
Beacons:
a.
Beacon specifications,
b.
FGB coding and protocols:

G-7

-
15 Hex ID,
-
User and Location protocols (User, Standard and National),
-
Orbitography and reference beacons,
-
Time reference beacon,
c.
SGB coding:
-
23 Hex ID,
-
SGB benefits to SAR,
d.
Familiarity with beacon decode app on C/S website,
e.
Beacon homing and sweep,
f.
Beacon registration information SIT formats (925,926),
g.
Importance of beacon registration,
h.
IBRD- who can register beacons and how to access data (password protected),
i.
Beacon testing policy, actions to take if live test is requested,
j.
Beacon disposal,
k.
Beacon Types and features:
-
ELT,
-
ELT(DT),
-
EPIRB,
-
PLB,
-
RLS,
-
FGB vs SGB,
-
SSAS.
Training resources:
•
Document C/S G.010, MCC Handbook,
•
Document C/S G.007, RCC Handbook,
•
Document C/S S.007, Handbook of Beacon Regulations,
•
Document C/S A.003, Annex I, System Level Test,
•
Beacon decoder app on Cospas-Sarsat website,
•
Beacon coding guide on Cospas-Sarsat website,
•
Video Playlist: Training Resources,
•
Video Playlist: About Owning a Beacon.
G.3.10 Communications:
a.
A working knowledge of English to enable timely and effective communications
with other MCC operators and the nodal MCC and to ensure understanding of
System documents,
b.
Networks used nationally,
c.
Network security,
d.
FTPV Standard,
e.
AFTN-AMHS Standard,
f.
Email,
g.
LUT to MCC communications.

G-8

Training resources:
•
Document C/S G.010, MCC Handbook,
•
Document C/S G.007, RCC Handbook.
G.3.11 Contingency Procedures:
a.
Back-up procedures – how to enter and exit backup status,
b.
How to back up another MCC when requested,
c.
Own back-up MCC and impact on other MCCs,
d.
LUT data to non-parent MCC,
e.
Use of email (or other means, e.g., WhatsApp) for transfer of SIT messages,
f.
Re-routing alert data between MCCs,
g.
System support staff contact numbers and availability.
Training resources:
•
Document C/S G.010, MCC Handbook,
•
Document C/S A.001, Data Distribution Plan (DDP).
G.3.12 Documentation Set:
a.
Manufacturers’ LUT and MCC operator manuals:
-
Operators to acquaint themselves with the contents,
b.
Cospas-Sarsat documents relevant to MCC operators and available for reference:
-
Document C/S G.010, MCC Handbook,
-
Document C/S G.007, RCC Handbook,
-
Document C/S A.001 – Cospas-Sarsat Data Distribution Plan (DDP),
-
Document C/S A.002 – Cospas-Sarsat Mission Control Centres Standard
Interface Description (SID),
-
Document C/S A.003 – Cospas-Sarsat System Monitoring and Reporting,
-
Document C/S T.001 – Specification for Cospas-Sarsat 406 MHz Distress
Beacons,
-
Document C/S T.018 – Specification for Second-Generation Cospas-
Sarsat 406-MHz Distress Beacons.
G.3.13 Competency Check:
[To be determined nationally]
G.3.14 On-the-Job Training:
The MCC on-the-job training (OJT) is an important way in which MCC operators acquire
knowledge to perform their functions at work. It should be performed after completing
classroom instruction and should be carried out at the MCC operator station with supervision
by a senior operator. To be most effective, an OJT program should include:

G-9

G.3.14.1
Working Time Schedule:
Documentation of the operator’s work hours.
G.3.14.2
Training Plan (subject to be covered):
a.
List of the MCC operator tasks and competencies, including at least:
i.
Tasks described at Annex G of document C/S A.006, declaration of DMCC
operator capabilities,
ii.
As applicable, the additional tasks and competencies:
▪
Demonstration of the ability to liaise with nodal MCC and RCCs in
English, if appropriate,
▪
Conduct annual System test,
▪
Use of MCC software and local interface,
▪
Interpretation of SIT messages,
▪
Decoding of 15, 22, 23 and 30 Hex messages,
▪
Actions upon receiving QMS warning messages,
▪
Actions to be taken when notified of live beacon tests,
▪
Use of national and international beacon registries (IBRD),
▪
Use of MCC communication facilities (phone, SAR website, fax,
etc.),
▪
Statistics recording and reporting,
▪
Case handling and recording,
b.
List of the nodal MCC operator tasks and competencies, including at least:
i.
Ensure orbit TCAL and SARP data have been transmitted to the DDR
MCCs,
ii.
On receipt of QMS analysis report, review and transmit appropriate
warning, non-conformity and conformity messages and update the Cospas-
Sarsat website
iii.
Aware of manufacturer and Cospas-Sarsat documentation
iv.
Aware of nodal MCC back-up procedures plus any individual MCC
procedures
v.
Respond to alarms and warnings and any sign of anomalies, especially data
distribution anomalies, and seek system manager support if in doubt at any
time
vi.
Focal point for Cospas-Sarsat matters thus have a comprehensive
knowledge of the System in general (see Annex G of C/S A.006)
vii.
Support and assistance to developing MCCs within DDR (see Annex F of
C/S A.006)
viii. Testing of communication links with all MCCs in DDR and for the back-up
DDR (see Annex G of C/S A.006)
ix.
Monthly communication checks with SPOCs and reporting to Cospas Sarsat
Secretariat
x.
Monitor operation of Cospas Sarsat System in the DDR (see Annex G of
C/S A.006)

G-10

xi.
Constant monitoring of communications within DDR and outside to nodal
MCCs
xii.
Access to foreign language interpreters
xiii. Assist system manager in the commissioning of new MCCs, if required
xiv. Good knowledge of beacon testing procedures and policy
Training resources:
•
Document C/S G.010, MCC Handbook
•
Document C/S S.007, Handbook of Beacon Regulations
•
Document C/S A.003, Annex I, System Level Test
•
Document C/S A.006,   Mission Control Centre Commissioning Standard
•
Beacon decoder app on Cospas-Sarsat website
•
Video Playlist: Training Resources
G.3.14.3
MCC Operator Checkout and Certification:
Upon completion of the practical training portion of the program, the new operator shall
be given an MCC Operator Checkout to cover all the items in the Cospas-Sarsat model
course.
G.3.14.4
Recurrent Training/Recertification
a.
Operator Recurrent Exam,
b.
Operator Continuation Training (operator refresher training).
- END OF ANNEX G -
- END OF DOCUMENT -

Cospas-Sarsat Secretariat
1250 René-Lévesque Blvd. West, Suite 4215, Montreal (Quebec) H3B 4W8 Canada
Telephone: +1 514 500 7999
Fax: +1 514 500 7996
Email: mail@cospas-sarsat.int
Website: http://www.cospas-sarsat.int