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

---
title: "A001: C/S A.001 Issue 8 - Rev.11"
description: "Official Cospas-Sarsat A-series document A001"
sidebar:
  badge:
    text: "A"
    variant: "note"
# Extended Cospas-Sarsat metadata
documentId: "A001"
series: "A"
seriesName: "Operational"
documentType: "operational"
isLatest: true
issue: 8
revision: 11
documentDate: "October 2025"
originalTitle: "C/S A.001 Issue 8 - Rev.11"
---

> **📋 Document Information**
>
> **Series:** A-Series (Operational)
> **Version:** Issue 8 - Revision 11
> **Date:** October 2025
> **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents)

---

COSPAS-SARSAT
DATA DISTRIBUTION PLAN
C/S A.001
Issue 8 – Revision 11

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


COSPAS-SARSAT DATA DISTRIBUTION PLAN
History
Issue
Revision
Date
Comments


Issue of original Cospas-Sarsat Operations Plan.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


TABLE OF CONTENTS
Page
1.
INTRODUCTION ....................................................................................................... 1-1
1.1
Overview .............................................................................................................. 1-1
1.2
Document Objective ............................................................................................. 1-1
1.3
Document Organization ....................................................................................... 1-1
1.4
Reference Documents .......................................................................................... 1-2
2.
GENERAL OPERATIONAL CONCEPT ................................................................ 2-1
2.1
General Alert Data Flow ...................................................................................... 2-1
2.2
Alert Data Distribution Principles ........................................................................ 2-1
2.3
Service Area of a Cospas-Sarsat MCC ................................................................ 2-2
2.4
Data Distribution Regions .................................................................................... 2-2
2.5
General Flow of System Information ................................................................... 2-3
3.
PROCEDURES ............................................................................................................ 3-1
3.1
General Procedures for the Distribution of Cospas-Sarsat Alert Data ................. 3-1
3.1.1 Introduction .............................................................................................. 3-1
3.1.2 Geographical Sorting of Alert Data .......................................................... 3-2
3.1.3 Message Formats ...................................................................................... 3-2
3.1.4 Beacon Identification................................................................................ 3-2
3.2
Alert Data Distribution Procedures ...................................................................... 3-7
3.2.1 Doppler, DOA and Encoded Positions ..................................................... 3-7
3.2.2 Validation of Beacon Message Data ........................................................ 3-7
3.2.3 Processing Multiple Alerts for the Same Beacon Identification .............. 3-8
3.2.4 Confirmation of Beacon Positions ......................................................... 3-14
3.2.5 Continued Transmission after Position Confirmation ............................ 3-15
3.2.6 Exchange of Ship Security Alerts........................................................... 3-16
3.2.7 Requesting Transmission of Alerts ........................................................ 3-17
3.2.8 Exchange of Unlocated Alerts ................................................................ 3-17
3.2.9 Combined LEOSAR/GEOSAR/MEOSAR Processing .......................... 3-18
3.2.10 Filtering Old Alert Data.......................................................................... 3-18
3.2.11 Cancellation Messages ........................................................................... 3-18
3.2.12 Processing Alert Information Based on TAC ......................................... 3-18
3.3
Notification of Country of Beacon Registration (NOCR) Service .................... 3-18
3.4
Exchange of Beacon Registration Information .................................................. 3-19
3.5
System Information ............................................................................................ 3-19
3.6
System Status Changes ....................................................................................... 3-20
3.6.1 Space Segment Status ............................................................................. 3-20


3.6.2 Changes of Operational Capabilities ...................................................... 3-21
3.6.3 System Failures ...................................................................................... 3-21
3.6.4 Scheduled Outages ................................................................................. 3-21
3.6.5 Scheduled Satellite Manoeuvres............................................................. 3-22
3.6.6 Reactivation of the SARP Instrument .................................................... 3-25
3.6.7 Space Segment Anomaly Reporting Procedures .................................... 3-25
3.7
Contingency Procedures ..................................................................................... 3-26
3.7.1 Operational Backup ................................................................................ 3-26
3.7.2 Backup Test ............................................................................................ 3-27
3.7.3 Backup Timing ....................................................................................... 3-28
3.7.4 Long-term Backup and Restoration of Operations ................................. 3-28
3.7.5 Distribution of MEOSAR Alerts to MCCs that Are Only
LEOSAR/GEOSAR-Capable ................................................................. 3-29
3.7.6 Distribution of Second-Generation-Beacon (SGB) Alerts to MCCs that
Are Only First-Generation-Beacon (FGB)-Capable .............................. 3-30
3.7.7 Distribution of Alerts for RLS-Capable FGBs to MCCs that Are Not FGB-
RLS-Capable .......................................................................................... 3-30
3.7.8 Distribution of FGB-ELT(DT) Alerts to MCCs that Are Not FGB-
ELT(DT)-Capable .................................................................................. 3-30
3.7.9 Distribution of Notifications for RLS-Capable FGB Alerts to the RLSP on
Behalf of MCCs that Are Not FGB-RLS-Capable ................................. 3-31
3.7.10 Operational Distribution of Alert Data for SGBs ................................... 3-31
3.7.11 Distribution of ELT(DT) Alerts to the Location of an Aircraft in Distress
Repository (LADR) on Behalf of Nodal MCCs that Are Not LADR-
Capable ................................................................................................... 3-31
3.7.12 Distribution of Alerts for TWC-Capable Beacon to MCCs that Are Not
TWC-Capable ......................................................................................... 3-31
3.8
Exchange of Test and Exercise Data .................................................................. 3-32
3.8.1 Coordination of Beacon Tests ................................................................ 3-32
3.8.2 Exchange of Test Messages.................................................................... 3-32
3.9
Archived Information ......................................................................................... 3-32
3.10 Communication Networks .................................................................................. 3-33
3.11 Return Link Service (RLS) ................................................................................ 3-33
3.12 Return Link Service – Two-Way Communication (TWC) ................................ 3-33
3.13 Location of an Aircraft in Distress Repository (LADR) for ELT(DT) Alert
Data .................................................................................................................... 3-34
3.13.1 LADR Data Provider (LDP) ................................................................... 3-34
3.13.2 LADR Position Type Priority ................................................................. 3-34
3.13.3 Distribution by MCCs ............................................................................ 3-34
4.
OPERATIONAL PROCEDURES FOR COSPAS-SARSAT MCCs ...................... 4-1
4.1
Data Distribution Regions and Inter-MCC Data Exchange ................................. 4-1


4.1.1 Introduction .............................................................................................. 4-1
4.1.2 Definition of DDR .................................................................................... 4-1
4.1.3 Data Exchange Between DDRs ................................................................ 4-2
4.1.4 Data Exchange Within DDRs ................................................................... 4-3
4.1.5 Inter-MCC Routing of Alert Data ............................................................ 4-8
4.1.6 Inter-MCC Routing of System Information ............................................. 4-8
4.2
Detailed Implementation of Data Distribution Procedures ................................ 4-15
4.2.1 Alert Message Validation (Filtering Anomalous Data) .......................... 4-15
4.2.2 Position Matching ................................................................................... 4-25
4.2.3 Position Confirmation ............................................................................ 4-27
4.2.4 Procedures to Determine Better Quality LEOSAR Alert Data for Same
Beacon Event Position Conflicts ............................................................ 4-27
4.2.5 Detailed Procedures for Alert Data Distribution .................................... 4-29
4.2.6 Distribution of Beacon Registration Information ................................... 4-42
4.2.7 NOCR Procedures .................................................................................. 4-43
4.2.8 Distribution of 406 MHz Ship Security Alerts ....................................... 4-44
4.2.9 Processing and Distribution of 406 MHz Interference Data .................. 4-47
4.2.10 Return Link Service (RLS) Procedures .................................................. 4-47
4.2.11 Two-Way Communication (TWC) Procedures ...................................... 4-49
4.2.12 Cancellation Message Procedures .......................................................... 4-52
4.2.13 SGB example .......................................................................................... 4-53
4.3
Procedures for the Co-Ordination of Beacon Tests ........................................... 4-54
4.4
LEOLUT Orbit Vector Update Method ............................................................. 4-57
5.
COSPAS-SARSAT SPACE AND GROUND SEGMENT DESCRIPTION .......... 5-1
5.1
SID Implementation Status .................................................................................. 5-1
5.1.2 Alert and Narrative Messages .................................................................. 5-2
5.2
Status of Space Segment ...................................................................................... 5-3
5.3
Description of Cospas-Sarsat MCCs .................................................................... 5-8
5.3.1 General ..................................................................................................... 5-8
Hyperlinks to MCC Sections
AEMCC
CMC
IDMCC
NMCC
TAMCC
ALMCC
CMCC
INMCC
PAMCC
TGMCC
ARMCC
CNMCC
ITMCC
PEMCC
THMCC
ASMCC
CYMCC
JAMCC
QAMCC
TRMCC
AUMCC
FMCC
KOMCC
SAMCC
UKMCC
BRMCC
GRMCC
MYMCC
SIMCC
USMCC
CHMCC
HKMCC
NIMCC
SPMCC
VNMCC


LIST OF TABLES
Table 3-1: Reference Times per Data Type for ELT(DT)s ....................................................... 3-12
Table 3-2: Notification Level for Failure or Outage .................................................................. 3-21
Table 4-1: MCC Data Routing Matrix (1/2) ................................................................................ 4-9
Table 4-2: System Information Distribution (1/4) ..................................................................... 4-11
Table 4-3: MCC Action Based on SIT Format .......................................................................... 4-17
Table 4-4: 406 MHz Alert Message Validation ......................................................................... 4-17
Table 4-5: MCC Action Based on Message Field Content ........................................................ 4-18
Table 4-6: Protocol Validation for 406 MHz Alert Messages ................................................... 4-19
Table 4-7: Rotating Field Validation for SGB* ......................................................................... 4-23
Table 4-8: Procedures to Determine Better Quality Alert Data  for Same Beacon Event Doppler
Position Conflicts ............................................................................................... 4-28
Table 4-9: Definition of the Input, Status and Action Words for 406 MHz Alerts ................... 4-31
Table 4-10: Processing Matrix, Message Formats and Distribution of New 406 MHz
LEOSAR/GEOSAR Alerts ................................................................................ 4-34
Table 4-11: Processing Matrix, Message Formats and Distribution of New 406 MHz MEOSAR
Alerts .................................................................................................................. 4-35
Table 4-12: Special Processing for Sw2 Status .......................................................................... 4-40
Table 4-13: Special Processing for Sw3 Status .......................................................................... 4-40
Table 4-14: Special Processing for Sw4 Status .......................................................................... 4-41
Table 4-15: Special Processing for Sw5, Sw6 and Sw7 Status ................................................... 4-42
Table 4-16: Associated MCCs for Return Link Service Providers ............................................ 4-48
Table 4-17: Associated MCCs for TWC Service Providers ...................................................... 4-50
Table 4-18: Notification Time Requirement for Submission of Co-ordination Information
Indicated in Figure 4-17 ..................................................................................... 4-56
Table 4-19: Orbit Vector Update Method .................................................................................. 4-57


LIST OF FIGURES
Figure 3-1: 406 MHz Alert Data Distribution Procedures –  All Beacon Types Except ELT(DT)
When Alert Sites Are in Pre-G-Switch-Activation Status ................................... 3-4
Figure 3-2: 406 MHz Alert Data Distribution Procedures –  ELT(DT) Alert Sites Are in
Pre-G-Switch-Activation Status ........................................................................... 3-6
Figure 3-3: MCC Processing for Scheduled Satellite Manoeuvres ........................................... 3-24
Figure 4-1: Inter-Nodal Network Diagram .................................................................................. 4-2
Figure 4-2: Western DDR Network Diagram .............................................................................. 4-3
Figure 4-3: Central DDR Network Diagram ............................................................................... 4-4
Figure 4-4: Eastern DDR Network Diagram ............................................................................... 4-5
Figure 4-5: South West Pacific DDR Network Diagram ............................................................. 4-6
Figure 4-6: North West Pacific DDR Network Diagram ............................................................. 4-7
Figure 4-7: South Central DDR Network Diagram ..................................................................... 4-8
Figure 4-8: 406 MHz Alert Message Validation Flowchart ...................................................... 4-16
Figure 4-9: Unresolved Doppler Match Scenario (20-km Circles) ........................................... 4-26
Figure 4-10: Alert Data Processing Concept ............................................................................. 4-30
Figure 4-11: NOCR Example (FGB) ......................................................................................... 4-44
Figure 4-12: Ship Security Alert Examples (Scenario 1) .......................................................... 4-46
Figure 4-13: Ship Security Alert Examples (Scenario 2) .......................................................... 4-47
Figure 4-14: RLS Example (FGB) ............................................................................................. 4-49
Figure 4-15: TWC Example (SGB) ........................................................................................... 4-51
Figure 4-16: SGB Example ........................................................................................................ 4-54
Figure 4-17: Beacon Test Co-ordination Message .................................................................... 4-55
Figure 5-1: Standard Message for Reporting Satellite Payload Status ........................................ 5-4
Figure 5-2: Standard Message for Reporting Satellite Manoeuvres ............................................ 5-5
Figure 5-3: Standard Message for Reporting Reactivation of the SARP Instrument .................. 5-6
Figure 5-4: Standard Message for Reporting a Spacecraft Anomaly .......................................... 5-7

1-1

1.
INTRODUCTION
1.1
Overview
The primary purpose of the Cospas-Sarsat System is the provision of distress alert and location
data for search and rescue (SAR), using spacecraft and ground facilities to detect and locate the
signals of Cospas-Sarsat distress radio beacons operating on 406 MHz. The position of the distress
and other related information are transmitted to appropriate Distress authorities by the responsible
Cospas-Sarsat Mission Control Centre (MCC).
Distress authorities include:
a)
SAR authorities for all types of distress beacons, except ship security beacons; and
b)
competent authorities for ship security beacons.
Distress alert data (or alert data) includes data from all Cospas-Sarsat distress radio beacons
specified in documents C/S T.001 (Specification for First Generation Beacons or FGBs) and
C/S T.018 (Specification for Second Generation Beacons or SGBs), including data from
ELT(DTs) and cancellation messages.
1.2
Document Objective
The Cospas-Sarsat System is operated in accordance with the 1988 International Cospas-Sarsat
Programme Agreement (ICSPA) and related documents. The purpose of this document is to:
a)
establish basic data distribution principles; and
b)
define the corresponding procedures to be implemented by Cospas-Sarsat MCCs for
distributing Cospas-Sarsat alert data and System information.
1.3
Document Organization
The Cospas-Sarsat policy with regards to MCC operations is contained in the text of this Cospas-
Sarsat Data Distribution Plan (DDP).
A brief description of the Cospas-Sarsat operational concept is given in section 2. Section 3
describes the basic approach for exchanging System information between MCCs and distributing
alert data and notification of country of beacon registration (NOCR) messages to Distress
authorities.
Sections 4 and 5 to this document provide:
a)
a detailed description of the operational procedures to be applied by MCCs (section 4); and
b)
a description of the Cospas-Sarsat Space and Ground Segments (section 5).

1-2

1.4
Reference Documents
a.
C/S A.002 Cospas-Sarsat Mission Control Centres Standard Interface Description,
b.
C/S A.003 Cospas-Sarsat System Monitoring and Reporting,
c.
C/S A.005 Cospas-Sarsat Mission Control Centre Performance Specification and Design
Guidelines,
d.
C/S S.011 Cospas-Sarsat Glossary,
e.
C/S P.011 Cospas-Sarsat Programme Management Policy,
f.
C/S T.001 Specification for Cospas-Sarsat [First Generation] 406 MHz Distress Beacons
g.
C/S T.002 Cospas-Sarsat Local User Terminal Performance Specification and Design
Guidelines,
h.
C/S T.004 Cospas-Sarsat LEOSAR Space Segment Commissioning Standard,
i.
C/S T.009 Cospas-Sarsat GEOLUT Performance Specification and Design Guidelines,
j.
C/S T.013 Cospas-Sarsat GEOSAR Space Segment Commissioning Standard,
k.
C/S T.015 Cospas-Sarsat Specification and Type Approval Standard for 406 MHz Ship
Security Alert (SSAS) Beacons,
l.
C/S T.017 Cospas-Sarsat MEOSAR Space Segment Commissioning Standard,
m.
C/S T.018 Cospas-Sarsat Specification for Second-Generation 406-MHz Distress Beacons,
n.
C/S T.019  Cospas-Sarsat MEOLUT Performance Specification and Design Guidelines,
o.
C/S R.012 Cospas-Sarsat 406 MHz MEOSAR Implementation Plan,
p.
C/S R.025 Cospas-Sarsat Two-Way Communication Operational Concept and High-Level
Requirements,
q.
SAR/GALILEO Service Definition Document.
- END OF SECTION 1 -

2-1

2.
GENERAL OPERATIONAL CONCEPT
2.1
General Alert Data Flow
The distribution of Cospas-Sarsat alert data throughout the world is summarized as follows:
•
the LUTs receive the beacon signals relayed by the satellites,
•
the signals are processed, and alert data is sent to the associated MCC for distribution.
Each MCC distributes alert data according to this Cospas-Sarsat Data Distribution Plan (DDP),
and according to its own unique requirements and procedures, to any country within its service
area which has agreed to accept such services. Alert data is provided to Distress authorities,
including SPOCs, which are Rescue Coordination Centres (RCCs) or other recognized national
points of contact that will use the data to enable fast and effective rescue of persons in distress.
Any MCC receiving alert data relating to a distress beacon located outside its service area will
relay that information to another MCC or responsible Distress authorities in accordance with the
principles listed in section 2.2 and the agreed procedures detailed in this document.
2.2
Alert Data Distribution Principles
The exchange of alert data between MCCs in the Cospas-Sarsat System and its distribution to
Distress authorities is based on the following principles.
Cospas-Sarsat alert data should be:
•
validated at the MCC to ensure the reliability of distress information provided to Distress
authorities,
•
distributed in a timely manner to the appropriate Distress authorities, as determined by the
rules defined in this Data Distribution Plan,
•
provided to Distress authorities in accordance with the applicable Cospas-Sarsat procedures,
or procedures agreed bilaterally between an MCC and the Distress authorities in its service
area.
In the case of maritime emergencies, any MCC not able to deliver the alert to the responsible
Distress authority should forward the alert to an RCC in the same country as the MCC.
In the case of inland emergencies, any MCC not able to deliver the alert to the responsible Distress
authority should deliver the alert to an ARCC in the same country as the MCC and could also
contact the control tower of an international airport in the country concerned.
In addition, MCCs should follow the Cospas-Sarsat agreed procedures to:
•
filter out redundant alert messages,

2-2

•
confirm the position of distress beacons and notify all recipients of incorrect positions after
position has been confirmed (except for ELT(DT)s unless the ELT(DT) has been activated
by the beacon G-switch),
•
ensure through appropriate backup arrangements, the uninterrupted distribution of alert data.
An ELT(DT) alert site is considered in:
a)
“Post-G-Switch-Activation” status after the first alert indicating automatic activation by
the beacon (probably due to a crash) has been received:
•
for an FGB ELT(DT), this is when bits 107-108 are equal to “01”, and PDF-2 is
valid,
•
for an SGB ELT(DT), this is when ELT(DT) In-Flight Emergency Rotating Field
(\#1) Triggering event bits 186-189 in the beacon message (bits 32-35 in the rotating
field) are equal to “0100”, and the rotating field is valid; or
b)
“Pre-G-Switch-Activation” status otherwise.
2.3
Service Area of a Cospas-Sarsat MCC
An MCC 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”.
An MCC service area is defined by the list of SPOCs to which that MCC distributes Cospas-Sarsat
alert data. The list of countries / regions included in the service area of each MCC is provided at
section 5.3 of this document.
Nothing in this document or other Cospas-Sarsat System documents prevents the parties from
adopting other arrangements more suitable for the distribution of Cospas-Sarsat alert data at some
future date.
It is essential that MCCs establish appropriate arrangements with all the countries / SPOCs in their
service area on communication links to be used for the distribution of alert data. If such
arrangements have not been made for a particular country in the MCC service area, the MCC shall
notify its own national SAR authorities of any Cospas-Sarsat alert in that country's SRR, for
handling in accordance with national SAR procedures.
As new SPOCs are identified, either through agreements with Cospas-Sarsat or via other channels,
they will be incorporated into existing MCC service areas by mutual consent of the SPOC national
authority and the appropriate MCCs. All MCCs should be notified of new SPOCs.
2.4
Data Distribution Regions
A data distribution region (DDR) comprises two or more MCC service areas. Cospas-Sarsat alert
data and System information are exchanged between DDRs through a single MCC which acts as
the point of contact for that DDR. This MCC is identified as the nodal MCC of the DDR. However,

2-3

bilateral arrangements can be implemented between adjacent MCC service areas included in
different DDRs to facilitate the exchange of alert data in overlapping service areas or adjacent
search and rescue regions.
The DDR structure of the Cospas-Sarsat data distribution network is defined in section 4.1,
together with the specific arrangements for the exchange of alert data in each DDR.
2.5
General Flow of System Information
System information assists in the operation of the Cospas-Sarsat System. This information includes
Cospas-Sarsat satellite ephemeris and calibration data that affect location processing, messages
used for commanding the satellite SAR instruments, and notification messages providing the status
of System elements. The flow of System information through the Cospas-Sarsat System is detailed
in section 3.5.
- END OF SECTION 2 -

3-1

3.
PROCEDURES
3.1
General Procedures for the Distribution of Cospas-Sarsat Alert
Data
3.1.1
Introduction
Alert data (or “alert”) is the generic term for Cospas-Sarsat alert and position data derived from
406 MHz distress beacon signal processing. Alert data derived from beacon signals contains the
beacon identification and may contain beacon position information and other coded information.
Alert data includes cancellation messages transmitted by SGBs and FGB ELT(DT)s, which
indicate that the distress condition associated with a beacon activation has ceased.
Beacon signals are relayed via three search and rescue (SAR) satellite systems, low Earth orbit
(LEOSAR), geostationary Earth orbit (GEOSAR) and medium Earth orbit (MEOSAR). Position
data can be derived in three ways:
•
by Doppler processing via the tracking of a LEOSAR satellite receiving 406 MHz beacon
transmissions,
•
by difference of arrival (DOA) processing using time of arrival (TOA) and frequency of
arrival (FOA) measurements received from multiple MEOSAR satellites relaying the same
beacon transmissions,
•
by position data encoded in beacon messages.
MCCs receive alert data from their LUTs or from other MCCs and distribute this alert data to the
appropriate Distress authority in their service area or forward the alert data to another MCC. Alert
data received from a single LEOSAR satellite pass or in a single MCC message shall be processed
in Time of Closest Approach (TCA) or detection time order. MCCs shall transmit Cospas-Sarsat
alert data in accordance with the principles for data distribution listed in section 2.2. The
corresponding procedures are outlined in Figure 3-1 for all beacon types except ELT(DT) alert
sites in Pre-G-Switch-Activation status, in Figure 3-2 for ELT(DT) alert sites in Pre-G-Switch-
Activation status, and in the following sections. These procedures are further detailed at section
4.2.

3-2

3.1.2
Geographical Sorting of Alert Data
Except for ship security alert data (described in section 3.2.6) and unlocated alert data (described
in section 3.2.8), alert data are distributed according to the geographical sorting* of the available
position(s). The geographical distribution of alert data to SAR authorities is organized as follows:
a)
Beacon position is within an MCC's service area:
An MCC that receives alert data for a beacon position in its own service area forwards the
alert data to the appropriate SPOC or national RCC, in accordance with the applicable
Cospas-Sarsat or national procedures.
b)
Beacon position is within another MCC's service area:
An MCC that receives alert data for a beacon position in another MCC's service area
forwards the alert data to the appropriate MCC, in accordance with the applicable Cospas-
Sarsat procedures as described in sections 4.1 and 4.2.
c)
Unlocated alerts:
There will be occasions when a LEOLUT or MEOLUT is unable to calculate a location for
a beacon or a beacon is detected by a GEOLUT, and the only information available is the
beacon message. If this data does not contain an encoded position, the alert is unlocated. In
these cases, the only information available will be the digital identification contained in the
beacon message which includes a country code designating the country of registration of the
beacon. MCCs shall transmit this information to the country of registration according to the
procedure described in section 3.2.8.
3.1.3
Message Formats
Alert messages are exchanged between MCCs using standard formats which permit automatic
processing and retransmission of all data. These message formats are defined in the Cospas-Sarsat
Mission Control Centres Standard Interface Description (C/S A.002). The lists of message formats
that are implemented at each MCC are provided at section 5.1.
3.1.4
Beacon Identification
MCCs when transmitting narrative messages and making reference to beacon identification shall
provide the identification as specified below:
a)
FGB: 15 hexadecimal characters comprising bits 26 to 85 of the beacon message. If a
location protocol beacon is involved, the coarse position fields shall be set to the specified
default values.
* Tolerance criteria for geographical sorting and distribution of all alert messages to the correct alert data recipient are
described in Section “Processing Integrity” of document C/S A.005.

3-3

b)
SGB: either:
•
15 hexadecimal characters (bits 1 – 60, per Table “Hex ID Contents” of document
C/S T.018), or
•
23 hexadecimal characters (bits 1 – 92) per Table “Hex ID Contents” of document
C/S T.018.

3-4

LUTs
Validate
MCC
MCCs
Validate
First Alert for
Beacon?
Dop/DOA
Position
Available?
Encoded
Position
Available?
Encoded
Position
Matches Dop/
DOA\*?
Encoded
Position
Available?
Transmit Incident
Message Based on
Dop/DOA\*
Position(s)
Position Not
Confirmed
Transmit Position
Confirmation
Message to
Confirmed Position
Position Confirmed
Transmit Incident
Message Based on
Dop/DOA* and
Encoded Positions
Position Not
Confirmed
Transmit Incident
Message Based on
Encoded Position
Position Not
Confirmed
Transmit Incident
Message Based on
Country Code
Position Not
Confirmed
Yes
No
Notes:
\*
Dop/DOA refers to Doppler or DOA processing.
**
Redundant Data criteria include Same Beacon Event, Poor Quality Flag
Indicators, Distance Criterion, Rotating Data Field values, and Image Position
Determination (before position confirmation).
*** As per procedure in section 4.2.2.
Ship security alerts are always sent based on country code.
Yes
No
Yes
Yes
No
No
Yes
No
Figure 3-1: 406 MHz Alert Data Distribution Procedures –
All Beacon Types Except ELT(DT) When Alert Sites Are in Pre-G-Switch-Activation Status (1/2)

3-5

Redundant
Data?**
Archive
Yes
Position
Previously
Confirmed?
No
Continued
Transmission
Required?
Yes
Follow Procedures
for Continued
Transmission
Yes
Dop/DOA\*
Position
Available?
No
Encoded
Position
Available?
Yes
Dop/DOA\*
Position Matches
Previous
Position(s)**
No
Transmit Position
Conflict Message
Based on Dop/DOA\*
Positions
No
Position Not
Confirmed
Transmit Position
Confirmation
Message to
Resolved Position
and Prev.
Destinations or
Transmit
Unresolved Dop.
Position Match or
Image Position
Determination
Message to Doppler
Positions***
Yes
Encoded
Position
Available?
No
Archive
No
Previous Dop/DOA\*
Position(s) Available?
Yes
Encoded Position
Matches Dop/DOA\*
Position?**
Yes
Transmit Position
Confirmation
Message to
Resolved Position
and Previous
Destinations
Yes
Position Confirmed
Previous Valid
Encoded Position(s)
Available?
No
Encoded Position
Matches Previous
Position(s)?***
Yes
Position Confirmed
Position Not
Confirmed
Encoded Position
Matches Dop/DOA\*
Position?***
Yes
Transmit Alert
Message to Encoded
Position
No
Transmit Position
Conflict Message
Based on Dop/DOA\*
and/or Encoded
Position(s)
Position Not
Confirmed
Encoded or
Dop/DOA* Position Matches
Previous Alerts?***
No
No
Yes
Yes
Yes
No
Figure 3-1: 406 MHz Alert Data Distribution Procedures –
All Beacon Types Except-ELT(DT) When Alert Sites Are in Pre-G-Switch-Activation Status (2/2)

3-6

Figure 3-2: 406 MHz Alert Data Distribution Procedures –
ELT(DT) alert sites are in Pre-G-Switch-Activation status
No
No
Position not
Confirmed
Transmit Incident
Message Based on
DOA* Position(s)
Encoded
Position
Available?
No
Yes
Yes
Position not
Confirmed
Transmit Incident
Message Based on
Encoded Position(s)
Position not
Confirmed
Transmit Incident
Message Based on
DOA* and Encoded
Position(s)
Position not
Confirmed
Transmit Incident
Message Based on
Country Code***
DOA
Position
Available?
Encoded
Position
Available?
Yes
Validate
First or
New Alert?
**
Archive
LUTs
Validate
MCCs
MCCs
Notes:
\*
DOA refers to DOA position
**
Alert is new (i.e., non-redundant) based on difference in detect time vs.
previous alerts. ELT(DT) alerts are sent to SAR authorities. New alerts are
sent based on new Position data and sent to previous destinations.
*** Transmit first alert only.
Yes
No

![Image 1 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_1.png)

![Image 2 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_2.png)

![Image 3 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_3.png)

![Image 4 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_4.png)

![Image 5 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_5.png)

![Image 6 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_6.png)

![Image 7 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_7.png)

![Image 8 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_8.png)

![Image 9 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_9.png)

![Image 10 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_10.png)

![Image 11 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_11.png)

![Image 12 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_12.png)

![Image 13 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_13.png)

![Image 14 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_14.png)

![Image 15 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_15.png)

![Image 16 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_16.png)

![Image 17 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_17.png)

![Image 18 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_18.png)

![Image 19 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_19.png)

![Image 20 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_20.png)

![Image 21 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_21.png)

![Image 22 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_22.png)

![Image 23 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_23.png)

![Image 24 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_24.png)

![Image 25 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_25.png)

![Image 26 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_26.png)

![Image 27 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_27.png)

![Image 28 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_28.png)

![Image 29 from page 18](/images/cospas-sarsat/A-series/A001/A001_page_18_img_29.png)

3-7

3.2
Alert Data Distribution Procedures
3.2.1
Doppler, DOA and Encoded Positions
Position data provided by LEOLUT Doppler processing, provided by MEOLUT DOA processing,
and encoded in beacon messages, constitute independent sources of beacon position information.
All types of position data are used by MCCs in the filtering and geographical sorting process and
distributed with alerts to RCCs and/or SPOCs, in accordance with the procedures described
hereunder.
An MCC shall filter all Doppler position data generated for SGBs.
An MCC shall filter Doppler position data generated for FGB ELT(DT) alert sites in Pre-G-
Switch-Activation status as per section 2.2.
An MCC shall filter all DOA position data generated by a MEOLUT for ELT(DT)s, except:
a)
if the MEOLUT is commissioned to provide DOA locations for fast-moving beacons; or
b)
when the beacon alert site is in Post-G-Switch-Activation status as per section 2.2.
The MCC shall maintain separate configuration parameters to indicate if a MEOLUT is
commissioned to provide DOA locations for fast-moving FGBs and for fast-moving SGBs.
An MCC shall verify that each alert location that it receives is inside the footprint of each satellite
through which it was detected per the associated alert message, using the algorithm described in
the Appendix “Determining the Satellite Footprint Check” in document C/S A.002. If a Doppler
or DOA position fails this footprint check, then:
a)
the Doppler or DOA position data shall be processed;
b)
a warning shall be provided about the out of footprint position data in the alert distributed to
a Distress authority (per document C/S A.002); and
c)
the MCC operator shall be notified.
If an encoded position fails this footprint check, then the encoded position shall not be processed.
3.2.2
Validation of Beacon Message Data
Under various circumstances such as interference, weak beacon signals or high noise levels, the
LUT processing can produce erroneous alert data (i.e., processing anomalies) which may cause
false alerts.
The alert data produced by the LEOLUTs, GEOLUTs and MEOLUTs must be validated in
accordance with the requirements of documents C/S T.002, C/S T.009 and C/S T.019,
respectively. In addition, to avoid propagating invalid alerts through the Cospas-Sarsat Ground

3-8

Segment, the procedure for validating alert data described at section 4.2 shall be implemented at
the MCC level to satisfy the requirements of document C/S A.005.
3.2.3
Processing Multiple Alerts for the Same Beacon Identification
After validation, alert data received by an MCC shall be compared to previous information
concerning the same beacon identification which has already been processed by that MCC, where
the “same beacon identification” is based on the 15 hexadecimal beacon ID for FGBs and based
on the 23 hexadecimal beacon ID for SGBs, per the section 3.1.4.
Except for RLS-test protocol beacons or for specified tests, MCCs shall filter alert data (including
NOCRs) associated with test protocol beacon messages (including SGB messages with bit 43 =1
in the 154-bit main field and FGB ELT(DT) messages with bits 43 – 66 = all “1”s or all “0”s). The
detailed procedure for the RLS-test protocol beacons is described in section 4.2.10.
3.2.3.1 Resetting Beacon Activation Status
If the satellite detection time or time of closest approach of a new alert is more than 18 hours after
the detection time of the latest alert received by the MCC for the same beacon identification, then:
a)
the new alert shall be treated as a new beacon activation (i.e., the beacon activation status
word (Sw) is reset to zero, per section 4.2.5); and
b)
all alerts with any associated detection time not after all associated detection times of the
latest alert received by the MCC for the previous beacon activation shall be filtered from
MCC processing of the new beacon activation.
MCCs may reset the beacon activation status (i.e., open a new alert site) prior to the expiration of
this time threshold based on other criteria.
In addition, MCCs shall reset the beacon activation status after cancellation messages are
processed, as specified in section 3.2.11.
3.2.3.2 Filtering of Redundant Data
Position data from LEOLUT, GEOLUT and MEOLUT alerts shall be matched using the distance
criteria defined at section 4.2 of this DDP and the criteria for Position Confirmation described in
section 3.2.4. Prior to position confirmation, all previously received LEOSAR, GEOSAR and
MEOSAR data shall be used to attempt to confirm position, regardless of whether the previously
received data was deemed to be redundant.
For ELT(DT)s, special procedures are used to filter redundant data, as described in section
3.2.3.2.2. Procedures related to Position Confirmation, Distribution of Alerts with Better Quality
DOA Position, and Continued Transmission after Position Confirmation do not apply to ELT(DT)s
unless noted otherwise.

3-9

MCCs shall distribute alert data that is otherwise redundant for all SGBs, including ELT(DT)s, if
the Rotating Data field is usable (per validation rules in section 4.2.1.1.3 and 4.2.1.1.5), the
Rotating Data field type (beacon message bits 155-158) is not 15 (i.e., cancellation message), and
either:
a)
no alert has previously been sent that contains the same Rotating Data field type (beacon
message bits 155-158); or
b)
both:
i.
the associated detect time of the Rotating Data field is at least 10 minutes after the
most recent associated detect time for a previously sent alert that contained data for
the same Rotating Data field type; and
ii.
there is at least one difference in the new Rotating Data field (bits 159-202)
compared to the previously sent Rotating Data field of the same type with the most
recent associated detect time.
3.2.3.2.1
Filtering of Redundant Data for Beacons except ELT(DT)s
Alert data produced by LEOLUTs is considered to be for the same beacon event when it has the
same beacon identification (ID), same spacecraft and same time of closest approach (TCA) ± 20
minutes; otherwise LEOLUT alert data is considered to be for a different beacon event.
Prior to position confirmation, LEOLUT alert data for the same beacon ID is not redundant if it
can be used to confirm the position, because either:
a)
Doppler position data in the new alert matches Doppler position for a different beacon event
in a previous LEOLUT alert; or
b)
Doppler position data in the new alert matches DOA position in a MEOLUT alert; or
c)
Doppler position data in the new alert matches encoded position in a previous alert; or
d)
encoded position in the new alert matches either:
i.
Doppler position in the same alert, or
ii.
Doppler position in a previous alert, or
iii.
a DOA position.
Otherwise, LEOLUT alert data for the same beacon ID is deemed to be redundant if:
a)
the new alert message does not include Doppler position data and the encoded position
matches encoded position information previously sent by the MCC (per the matching test
for encoded position specified below); or
b)
position was previously confirmed, the new alert message includes Doppler position data, a
Doppler position in the new alert matches the confirmed position, a Doppler position in the
new alert matches a position in an alert previously sent for the same beacon event, and either:
i.
the new alert message does not include encoded position data, or

3-10

ii.
the encoded position data in the new alert message matches encoded position
information received earlier by the MCC; or
c)
the new alert message includes Doppler position data, each Doppler position in the new alert
matches a Doppler position in one alert previously sent for the same beacon event and, either:
i.
the new alert message does not include encoded position data, or
ii.
the encoded position data in the new alert message matches encoded position
information previously sent by the MCC (per the matching test for encoded position
specified below); or
d)
an alert with the same beacon ID has already been processed for the same beacon event and
the new alert message does not include Doppler position data or encoded position data.
Before position confirmation, LEOLUT alert data for the same beacon event should not be
considered redundant if it contains information on image position determination not previously
processed (see document C/S A.002, Appendix B.2 to Annex B entitled “Validating the Satellite
Footprint and LEOSAR Image Position”).
Alert data produced by MEOLUTs is considered to be a dependent beacon event based on the
criterion for setting the ‘Dependent Beacon Event’ flag defined at section 4.2.
Prior to position confirmation, MEOLUT alert data for the same beacon ID is not redundant if it
can be used to confirm the position, because either:
a)
DOA position data in the new alert matches DOA position for a non-dependent beacon event;
or
b)
DOA position data in the new alert matches a Doppler position; or
c)
DOA position data in the new alert matches encoded position in a previous alert; or
d)
encoded position in the new alert matches either:
i.
DOA position in the same alert, or
ii.
DOA position in a previous alert, or
iii.
a Doppler position.
Otherwise, MEOLUT alert data for the same beacon ID is deemed to be redundant if either:
a)
the new alert message does not include DOA position data and the encoded position matches
encoded position information previously sent by the MCC (per the matching test for encoded
position specified below); or
b)
the new alert message includes DOA position data, the DOA position in the new alert
matches a DOA position in an alert previously sent by the MCC for a dependent beacon
event and, either:
i.
the new alert message does not include encoded position data, or

3-11

ii.
the encoded position data in the new alert message matches encoded position
information previously sent by the MCC (per the matching test for encoded position
specified below); or
c)
an alert with the same beacon ID has already been processed for a dependent beacon event
and the new alert message does not include DOA position data or encoded position data.
However, prior to position confirmation, a dependent beacon event alert shall be transmitted if:
a)
the time of the latest beacon burst used to compute the new DOA position is more than five
(5) minutes after the time of the latest beacon burst used to compute all previously sent DOA
positions; or
b)
the new alert has better quality DOA position, per the procedure “Distribution of Alerts with
Better Quality DOA Position” in section 3.2.3.2.3; or
c)
the new alert is a position conflict alert and no more than four (4) position conflict alerts
have been sent that contain DOA position.
Prior to position confirmation, GEOLUT alert data for the same beacon ID is not redundant if it
can be used to confirm the position, because encoded position in the new alert matches either
Doppler or DOA position in a previous alert.
Otherwise, GEOLUT alert data produced by GEOLUTs for the same beacon ID identification is
deemed to be redundant if:
a)
the new alert message does not include encoded position data; or
b)
the encoded position data in the new alert message matches encoded position data previously
sent by the MCC (per the matching test for encoded position specified below).
To minimize redundant message traffic in the Ground Segment, MCCs shall not distribute alert
data which have been determined as redundant in accordance with the procedure described at
section 4.2. MCCs shall distribute alert data which have not been determined to be redundant.
The matching test for new encoded position data shall be performed with all encoded position data
previously received and forwarded (i.e., not deemed redundant) for the same beacon ID, taking
into account whether the encoded position is coarse (i.e., without usable encoded position in the
second protected field of the beacon message) or refined (i.e., with usable encoded position in the
second protected field of the beacon message), as follows:
a)
if the new encoded position is refined, and:
i.
no previous refined encoded position has been sent, then the new encoded position
is sent regardless of the difference with any previously sent coarse encoded position
(and the alert will be distributed as a “position update”), else
ii.
another refined encoded position was previously sent, then the new encoded
position is sent if it:
a.
does not match any previously sent refined encoded position, or

3-12

b.
it has a detect time more recent than any previously sent refined encoded
position and does not match any previously sent refined encoded location with
the most recent detect time; and
b)
if the new encoded position is coarse, and:
i.
it matches the position encoded in the first protected field of a previously sent
beacon message, then it shall be deemed redundant, else
ii.
the new encoded position is sent if it does not match any previously sent encoded
position (coarse or refined).
LEOSAR, GEOSAR and MEOSAR data deemed to be redundant shall not be used to determine
whether subsequent data is redundant.
3.2.3.2.2
Filtering of Redundant Data for ELT(DT)s
To meet ICAO requirements to locate crashed aircraft, alerts for ELT(DT)s are distributed
frequently during the period soon after beacon activation. To support the distribution of ELT(DT)
alerts, a reference time is associated with each alert for an ELT(DT) as follows:
Table 3-1: Reference Times per Data Type for ELT(DT)s
Alert Type
Reference Time
LEOSAR
Detect Time or TCA provided by the LEOLUT (per document C/S A.002
Message Field \#14)
GEOSAR
Detect Time provided by the GEOLUT (per document C/S A.002 Message
Field \#14)
MEOSAR
Time of last beacon burst (per document C/S A.002 Message Field \#14b)
Inclusion of DOA and Doppler positions is subject to the specifications in section 3.2.1.
The MCC shall send a new alert received for an ELT(DT) if:
a)
no previous alert has been sent for the beacon Identification (i.e., beacon activation status
word (Sw) is zero); or
b)
the new alert contains a DOA or Doppler position and no previous alert with DOA or
Doppler position has been sent; or
c)
the new alert contains an encoded position and no previous alert with encoded position has
been sent; or

3-13

d)
the reference time of the new alert is within 30 seconds of the earliest reference time for all
previously received alerts, and either1:
i.
it differs by at least three (3) seconds from the reference time for all previously sent
alerts; or
ii.
it differs by at least three (3) seconds from the reference time for all previously sent
alerts with a DOA or Doppler position and the new alert contains a DOA or Doppler
position; or
iii.  it differs by at least three (3) seconds from the reference time for all previously sent
alerts with refined encoded position and the new alert contains refined encoded
position (FGBs only); or
iv.
it differs by at least three (3) seconds from the reference time for all previously sent
alerts with encoded position and the new alert contains encoded position; or
e)
the new alert contains a DOA, Doppler or encoded position, and the reference time of the
new alert differs by at least 10 minutes from the reference time for all previously sent alerts2;
or
f)
based on service area information available to the MCC, the new alert contains a DOA,
Doppler or encoded position located in an area for which the associated MCC or associated
Distress authority has not previously been sent an alert; or
g)
the new alert contains a cancellation message as specified in section 3.2.11; or
h)
the new alert contains an activation type (defined in document C/S A.002, MF \#58) that
differs from the activation type contained in the previous sent alert.
In addition, if the current time is at least 10 minutes more recent than the reference time for all
previously sent alerts, then the MCC shall send the best solution with a reference time more recent
than the time a message was last sent3 for all previously sent alerts, where the priority for the best
solution is as follows:
a)
the solution with the most recent reference time and either:
i.
encoded position for an SGB, or
ii.
a refined encoded position for an FGB;
b)
the solution with the most recent reference time and a DOA or Doppler position; or
c)
the solution with the most recent reference time and coarse encoded position for an FGB; or
1 The logic behind the text below is to guarantee, as much as possible, that all bursts transmitted by the ELT(DT)
beacon during the first 30 seconds of activation are distributed by the MCC.
2 This clause (item (e)) should only be applied if the best solution logic that follows has yet to be implemented.
3 The “time a message was last sent” is defined as the time when the MCC alert processing software component sets
the actual data delivery process into action for all destinations.

3-14

d)
the solution with the most recent reference time and no position data.
The time thresholds specified above shall be configurable separately.
MCCs shall distribute alert data for ELT(DT)s to SAR authorities, as specified in section 3.1.2.
Subsequent ELT(DT) alerts shall be distributed based on new position data and to previous
destinations. The distribution of alerts for ELT(DT)s for each beacon activation shall be
configurable per SAR authority.
3.2.3.2.3
Distribution of Alerts with Better Quality DOA Position
Before or after position confirmation, a new alert with DOA position shall be transmitted for all
types of beacons except ELT(DT) when alert sites are in Pre-G-Switch-Activation status, if
a)
the Expected Horizontal Error (EHE) (Message Field \#89 in document C/S A.002) was
never available* for all previously transmitted DOA positions and the new EHE of the
new DOA position is available\*; or
b)
the EHE is available*  for a previously transmitted DOA position, the EHE of the new
DOA position is available and is:
i.
less than 150 nm (277.8 km);
ii.
at least 2 nm (3.704 km) less than the lowest EHE for all previously transmitted
DOA position alerts for FGBs;
iii.
at least 1.9 nm (3.519 km) less than the lowest EHE for all previously transmitted
DOA position alerts for SGBs; and
iv.
at least 50% less than the lowest EHE for all previously transmitted DOA position
alerts.
Each of the above criteria shall be independently configurable.
Note: (\*) The EHE is considered available if the MEOLUT providing the DOA alert is
commissioned for DOA and EHE, and the EHE value is set to a non-default value.
3.2.4
Confirmation of Beacon Positions
The objective of this process is to confirm the position of a beacon on the basis of information
provided by two independent sources.
A Doppler location always includes two sets of position data, the ‘true’ and the ‘image’ solutions
which are symmetrical relative to the trace of the orbit. Each solution is associated with a
probability which is generally sufficient to resolve the Doppler ambiguity. However, the actual
characteristics of the 406 MHz transmission are not known by the receiving LUT and reliable
ambiguity resolution of the Doppler solutions can only be achieved with a set of Doppler positions
from a different beacon event, a DOA position, or an external source of data such as position data
encoded in the beacon message. Ambiguity resolution is a specific type of position confirmation;

3-15

the ‘true’ position is a type of confirmed position, the ‘image’ position is a type of incorrect
position and an unresolved (Doppler) position is a type of unconfirmed position.
While a DOA position does not have inherent ambiguity, confirmation of a DOA position is
required as errors may occur. Confirmation of a DOA position can only be achieved with a DOA
position from a different beacon event, a Doppler position, or an external source of data such as
position data encoded in the beacon message.
A beacon message with encoded position data provides a unique position which may be very
accurate. However, errors may occur and confirmation of the encoded position via an independent
source is desirable. As several alert messages from the same beacon received through different
satellites and/or different LUTs can all originate from the same beacon transmission and, therefore,
from the same navigational data, confirmation of encoded position data can only be provided by a
Doppler or DOA position matching the encoded position.
Therefore, independent position information will consist of:
a)
Doppler positions obtained from two different beacon events;
b)
Doppler position and encoded position data; or
c)
DOA positions obtained from two different beacon events; or
d)
DOA position and encoded position data; or
e)
Doppler position and DOA position.
The beacon position is confirmed only if two independent sets of position data match the distance
criteria specified at section 4.2.
Alert data for beacons located outside an MCC’s service area shall be forwarded until position is
confirmed. Prior to position confirmation, alert data shall be transmitted to all previous message
recipients. Once position is confirmed, a position confirmation message shall be transmitted to
each MCC and/or SPOC that has the resolved position or a previous incorrect position in its MCC
service area, or its SAR Region(s), respectively.
3.2.5
Continued Transmission after Position Confirmation
An MCC shall have the capability to suppress or to continue transmission of alert data for selected
beacons as requested by an MCC or SPOC. An MCC requesting continued transmission by another
MCC shall also request continued transmission by any nodal MCCs involved in the distribution of
the continued transmission alert data.
After position confirmation, alert data shall not be geographically sorted according to the received
position but sent to the same MCC or SPOC that has the resolved position in its MCC service area
or its SAR Region, respectively, or requested continued transmission. Ship security alerts are not
sent based on the received position, as described in section 3.2.6.

3-16

Alert data shall not be distributed after position confirmation to an MCC that has requested that it
not receive alert data for its service area after position confirmation. Therefore, nodal MCCs (and
Central DDR MCCs) shall be capable of filtering alert data after position confirmation based on
the request of the destination MCC. MCCs that do not want to receive alert data after position
confirmation shall notify other MCCs of this request and shall request the Secretariat to update the
associated table on the Cospas-Sarsat website.
After position confirmation, MCCs shall send a new alert when:
a)
a non-redundant encoded position is received (per section 3.2.3); or
b)
Doppler position is received for a new beacon event; or
c)
a Doppler position conflict alert is received for the same beacon event, provided that the new
alert has sufficient quality (per section 4.2.4); or
d)
the new alert has DOA position that matches the confirmed position and no alert with DOA
position that matches the confirmed position has previously been sent; or
e)
the new alert has better quality DOA position, per the procedure “Distribution of Alerts with
Better Quality DOA Position” in section 3.2.3.2.3; or
f)
a DOA position alert matching the confirmed position is received, provided that the time of
the latest beacon burst used to compute the new DOA position is more than 15 minutes after
the time of the latest beacon burst used to compute all previously sent DOA positions that
matched the confirmed position; or
g)
a DOA position conflict alert is received, and no DOA position conflict alert has previously
been sent; or
h)
a DOA position conflict alert is received, provided that the time of the latest beacon burst
used to compute the new DOA position is more than 10 minutes after the time of the latest
beacon burst used to compute all previously sent DOA position conflict alerts.
3.2.6
Exchange of Ship Security Alerts
Ship security alerts are initiated and transmitted by vessels whose security is threatened and who
need to notify a competent authority designated by the flag state. The transmission of ship security
alerts is based on the country code contained in the beacon identification, which is then used to
route the alert to the appropriate MCC or competent authority.
MCCs will exchange ship security alerts using the formats specified in the document C/S A.002
and according to the ship security alert distribution procedures described in section 4.2 of this
DDP.
An MCC shall transmit a ship security alert only to the MCC or competent authority associated
with the country code. An MCC shall not transmit a ship security alert to the RCC or SPOC
associated with the location of the alert.

3-17

3.2.7
Requesting Transmission of Alerts
MCCs, SPOCs or RCCs may request transmission of alerts by geographical area, or 15
hexadecimal beacon identifier (for FGBs or SGBs), or 23 hexadecimal beacon identifier (for
SGBs) per the section 3.1.4. The MCC processing of such a request shall be based on the 15
hexadecimal beacon identifier per section 3.1.4.
If the request is by geographical area, then the request should specify the area for which new alerts
would be provided, either as a radius in nautical miles around a position or as a rectangle defined
by two opposing corner positions.
The request should indicate the MCCs that would receive alerts for that area in real time. A nodal
MCC that receives a request for transmission shall forward the request to the appropriate MCCs,
to ensure that the requested alerts are sent.
The requesting agency should indicate when transmissions are to be discontinued.
3.2.8
Exchange of Unlocated Alerts
When a LEOLUT or MEOLUT is unable to calculate a location for a beacon, or a beacon message
is detected by a GEOLUT, the only information available is the beacon message. If this data does
not contain an encoded position, the alert is unlocated. An unlocated alert shall be distributed using
the country code in the beacon identification for routing to the appropriate MCC or Distress
authority, as provided on the Cospas-Sarsat website "Contact List" for "406 MHz Beacon
Registers (available 24/7 for SAR services)".
Unlocated alerts shall be validated at LUT and MCC level in accordance with the applicable
procedure.
MCCs shall exchange unlocated alert messages using the formats specified in the document C/S
A.002 and according to the alert distribution procedures described in section 4.1 and section 3.1.2
of this DDP.
Prior to position confirmation, an MCC shall transmit an unlocated alert message only if no
position information has been received previously for the same beacon identification. To increase
the probability of Image Position Determination (as defined in document C/S A.002), multiple
LEOLUT/GEOLUT unlocated alert messages may be transmitted for a beacon other than an
ELT(DT), provided that:
a)
only one unlocated alert message is sent per GEOSAR satellite; and
b)
only one unlocated alert message is sent per LEOSAR satellite beacon event.
After position confirmation, an MCC shall transmit an unlocated alert for an RLS-capable beacon
as specified in section 4.2.10.

3-18

3.2.9
Combined LEOSAR/GEOSAR/MEOSAR Processing
For the purposes of alert data distribution procedures, solutions derived from combined
LEOSAR/GEOSAR processing shall be treated as LEOSAR alerts. Solutions derived from
MEOSAR processing that contain LEOSAR and/or GEOSAR data shall be treated as MEOSAR
alerts.
3.2.10 Filtering Old Alert Data
Alert data with a detect time older than 24 hours shall be filtered.
3.2.11 Cancellation Messages
Cancellation messages are transmitted by SGBs and ELT(DT)s to indicate that the distress
condition associated with a beacon activation has ceased. Cancellation messages shall be verified
with a high degree of certainty before they are distributed to Distress authorities. The detailed
procedure for cancellation messages is described in section 4.2.12.
3.2.12 Processing Alert Information Based on TAC
MCCs shall provide information to relevant destinations (i.e., Distress authorities and FGB-only-
capable MCCs) based on the TAC number encoded in the beacon message (e.g., for SGB homing
characteristics) in SIT 985 messages, in accordance with document C/S A.002. An MCC shall:
a)
transmit a SIT 985 message to each relevant destination immediately after sending the first
alert message to that destination for an alert site (i.e., on beacon activation); and
b)
only transmit a single SIT 985 message to each relevant destination for an alert site (i.e., it
shall not transmit a SIT 985 message for any subsequent alert sent to a relevant destination
for an alert site).
Information associated with the TAC number shall be maintained at the MCC based on relevant
information provided at the Cospas-Sarsat website and provided in SIT 927 messages.
The FMCC sends information associated with new TAC numbers in SIT 927 messages for SGBs
and in SIT 605 messages for FGBs.
3.3
Notification of Country of Beacon Registration (NOCR) Service
The NOCR service provides notification to the SPOC of a country when an alert is located outside
of that country’s SRR for a beacon associated to that country by its country code. The NOCR
service ensures that a country is notified whenever one of its beacons is activated. The NOCR
service is especially beneficial when a distress alert is located in an area of the world where suitable
search and rescue resources are not available to perform the SAR mission. This service provides
the parties responsible for the vessel, aircraft, or persons in distress an opportunity to assist the
SAR services in their response to the emergency situation.

3-19

An NOCR message should not be interpreted as a request for information. If necessary, requests
for information regarding the vehicle carrying a particular beacon should be made to the beacon
registry.
The detailed procedure for the NOCR service is described in section 4.2.7.
3.4
Exchange of Beacon Registration Information
It is essential that every country using beacons maintain a register where Distress authorities can
obtain vital information at any time. The maintenance of such a register is a national responsibility
and the release of information is subject to national regulations.
Each country using beacons should make appropriate arrangements to ensure 24-hour access to
their national register(s) by SAR services and inform Cospas-Sarsat of their point of contact.
Cospas-Sarsat Participants should also make appropriate arrangements with the associated MCC
listed on the Cospas-Sarsat website, to ensure fast and easy access to its national register via the
associated MCC.
IMO Assembly Resolution A.887(21) concerning registration databases of satellite EPIRBs
requires the EPIRB identification code to be included in the database amongst other SAR related
information. It is possible that the only means to query a database would be through the beacon ID
and thus it is imperative that the correct beacon ID usage be applied. The beacon ID, as described
in the Cospas-Sarsat Glossary (document C/S S.011) should be used whenever requests for beacon
registration information are made or provided.
3.5
System Information
System information messages include ephemeris or orbit vector messages, time and frequency
calibration messages, spacecraft telemetry and commands, Ground Segment elements and
spacecraft operational status, and narrative messages. Table 4-1 shows the network structure for
System information distribution and indicates the senders and receivers of each type of System
information. Orbitography beacons also provide System information. MCCs shall send
orbitography and reference beacon data to the associated nodal MCC to satisfy the Cospas-Sarsat
Quality Management System (QMS) continuous monitoring and objective assessment process
described in document C/S A.003. Information on orbitography beacons can be found on the
Cospas-Sarsat website at www.cospas-sarsat.int.
The CMC and the USMCC distribute orbit ephemeris data for the Cospas and Sarsat spacecraft
daily. They automatically receive, process, confirm by their own calculations and transmit the
ephemeris data to the other MCCs and their own LUTs.
Search and Rescue Repeater (SARR) frequency calibration offset data for a given LEOSAR
satellite is used by those LEOLUTs which perform combined LEO/GEO processing to adjust the
SARR frequency measurements obtained from that LEOSAR satellite. SARR frequency
calibration offset information is computed at the CMCC using a reference beacon. The CMCC
automatically sends SARR frequency calibration offset messages to other MCCs once per week,

3-20

as needed. SARR frequency calibration offset will be computed and distributed by the CMCC for
all LEOSAR satellites which have an operational SARR channel.
Time calibration data is used to convert the Sarsat Search and Rescue Processor (SARP) time code
to co-ordinated universal time (UTC). Time information provided for each 406 MHz data point
must be corrected for computing the beacon location. Time and frequency calibration information
for the Sarsat SARP is computed at the FMCC using signals from a time calibration platform
relayed through Sarsat spacecraft. The FMCC automatically sends SARP time calibration
messages to other MCCs once per week. Time calibration is not required for processing SAR
incident data from Cospas spacecraft.
Sarsat payload commands requested by the CMCC (for the SARR), the FMCC (for the SARP), or
the USMCC are co-ordinated, validated and then automatically forwarded by the USMCC to the
NOAA Satellite Operations Control Center (SOCC) for transmission to the NOAA spacecraft.
Verification of command execution is sent from the NOAA SOCC to the USMCC for transmission
to the FMCC or CMCC. The Cospas payload commands are generated by the CMC.
Narrative and coordination messages are exchanged between the MCCs. Requests for
retransmissions of messages will be addressed to the appropriate MCC. System information will
be archived until it is updated and retrieved and transmitted when requested.
Changes in orbitography beacon information may be updated by System status messages sent to
other MCCs.
3.6
System Status Changes
System status changes are the result of 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. These changes will impact the operation of
the Cospas-Sarsat System and should be notified to appropriate MCCs.
Space Segment Providers shall initiate System status messages to all MCCs whenever Space
Segment out-of-limit conditions or changes occur, and when changes in the satellite SAR
equipment are scheduled. The FMCC shall initiate notification of changes for Galileo satellites
and EUMETSAT Meteosat Second and Third Generation (MSG and MTG) satellites on behalf of
the associated Space Segment Providers. Ground Segment Operators shall initiate System status
messages for changes of Ground Segment status. All changes of System status shall be notified by
MCCs in accordance with this section and section 4.1.
3.6.1
Space Segment Status
Space Segment Providers shall provide notice to all Ground Segment Operators on the operational
status of the spacecraft payloads in accordance with documents C/S T.004, C/S T.013 and
C/S T.017. Payload status shall be declared with a System status message as described in section
5.2. Distribution of satellite ephemeris and SARP time calibration data, which may precede

3-21

declaration of Initial Operational Capability (IOC) status, shall not itself be understood as a
declaration of IOC status.
A satellite that is in IOC status shall be treated as though it were operational except that Ground
Segment Operators may at their option elect to not acquire data from it via their LUTs. All Ground
Segment Operators shall process alerts generated by other MCCs from this satellite data in their
MCCs. It is recommended that satellites in IOC status be given lower priority in LUT scheduling.
3.6.2
Changes of Operational Capabilities
Changes of operational capabilities resulting from new equipment or new processing which impact
the operation of the Cospas-Sarsat System, should be notified by the responsible MCC in
accordance with Table 3-2 and Table 4-1.
Changes of System status resulting from the decommissioning of System equipment should be
notified by the responsible MCC to all MCCs in accordance with Table 4-1.
Table 3-2: Notification Level for Failure or Outage
Failure or Outage
Notification Level
Space Segment
All MCCs should be notified
MCC
All MCCs and the reporting MCC’s
SPOCs should be notified
LUT
All MCCs should be notified
Communication Networks
Only affected MCCs should be notified
Orbitography beacons
All MCCs should be notified
3.6.3
System Failures
System status changes resulting from either a failure or outage of a System element or a System
function should be reported to the appropriate MCC in accordance with Table 3-2 and the System
Information Flow Diagram of Table 4-1. Nodal MCCs shall update System element status in the
appropriate section of the Cospas-Sarsat website in accordance with the Cospas-Sarsat Quality
Management System (QMS) continuous monitoring and assessment process, as described in
document C/S A.003.
3.6.4
Scheduled Outages
System status changes for any System element or function which result from scheduled outages
for maintenance, integration or testing, should be notified by the responsible MCC to all MCC(s)
and SPOCs in accordance with Table 3-2 and Table 4-1. The responsible MCC should provide
advance notification as early as possible before interrupting operations, including a description of

3-22

the planned backup arrangements (see sections 3.7 and 5.3). Additionally, the responsible MCC
should repeat the notification 24 hours prior to the scheduled activity.
The MCC that performs a backup shall inform by a narrative message SIT 915, the non-operational
MCC’s SPOCs of the failure of their associated MCC and that the originating MCC is performing
backup service according to section 3.7.
3.6.5
Scheduled Satellite Manoeuvres
Some LEOSAR satellites are subject to scheduled manoeuvres periodically, in order to maintain
their sun synchronous orbit and thus to increase their useful life.
A satellite may be manoeuvred in two ways, in-plane or out-of-plane. An in-plane manoeuvre is
issued to counteract the effect of drag on the semi-major axis. An in-plane manoeuvre changes
satellite position by an amount that increases with each subsequent orbit. An out-of-plane
manoeuvre is issued to counteract the effects of Luni-solar pull on inclination. An out-of-plane
manoeuvre changes satellite position by an amount that does not increase with subsequent orbits.
A satellite manoeuvre may induce significant Doppler location errors, due to the possible
application of incorrect orbit vectors by LEOLUTs. In order to mitigate the impact of planned
satellite manoeuvres on Doppler location accuracy, MCCs shall implement the following
procedures.
For each satellite that is subject to scheduled manoeuvres, one MCC shall be responsible for
notification about its manoeuvres and is designated the responsible MCC. The USMCC is the
responsible MCC for the manoeuvres of all LEOSAR satellites with Sarsat payloads.
The responsible MCC shall provide notification to all MCCs of the scheduled satellite manoeuvre.
The responsible MCC shall provide notification five (5) to seven (7) days in advance of a scheduled
satellite manoeuvre, to allow Ground Segment Providers adequate preparation time. The
responsible MCC shall repeat the notification 24 hours prior to the scheduled manoeuvre. The
responsible MCC shall provide notification of the execution of the satellite manoeuvre as soon as
possible after the manoeuvre is complete. If the maximum expected change in satellite position is
more than two (2) kilometers in the 24 hours following completion of the manoeuvre, then the
responsible MCC shall provide new orbit vectors for the satellite as soon as possible after the
manoeuvre is complete. Orbit vectors associated with a satellite manoeuvre shall be provided in a
SIT 216 message.
Notification of a satellite manoeuvre shall be provided in a System status message as described in
Figure 5-2 and in accordance with Table 4-1. The responsible MCC shall provide information on
the magnitude and duration of the expected change in satellite position. The magnitude should be
provided for the 24-hour period after the manoeuvre, when possible, since the impact of the change
should be negligible after 24 hours.

3-23

Based on notification of a satellite manoeuvre provided at least four (4) hours in advance of the
planned manoeuvre, MCCs shall:
a)
immediately after reception of the SIT 216 message, treat orbit ephemeris data received in
the SIT 216 message over a period of 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;
b)
use the validated SIT 216 orbit ephemeris data to immediately initialise orbit vectors at the
MCC and its associated LUTs; and
c)
notify its RCCs and SPOCs in alert messages sent for the manoeuvred satellite as specified
in document C/S A.002, if the maximum expected error in Doppler location exceeds 10
kilometres within 24 hours of the manoeuvre.
If notification of a satellite manoeuvre is not provided four (4) hours in advance of the planned
manoeuvre (e.g., when a satellite manoeuvre is executed to avoid a collision), within four (4) hours
of SIT 216 reception, MCCs shall:
a)
validate orbit ephemeris data received in the SIT 216 message (as described above);
b)
use the validated SIT 216 orbit ephemeris data to initialise orbit vectors at the MCC and its
associated LUT; and
c)
notify its RCCs and SPOCs in alert messages sent for the manoeuvred satellite (as described
above).
MCC responsibilities for scheduled satellite manoeuvres are outlined in Figure 3-3.

3-24

Figure 3-3: MCC Processing for Scheduled Satellite Manoeuvres

![Image 1 from page 36](/images/cospas-sarsat/A-series/A001/A001_page_36_img_1.png)

3-25

3.6.6
Reactivation of the SARP Instrument
On occasion, the SARP instrument on a satellite with a Sarsat payload is deactivated, due to an
unexpected or a scheduled outage. Since accurate SARP time calibration (TCAL) data is required
to compute accurate Doppler locations from SARP data, it is necessary that LEOLUTs be updated
with new SARP TCAL data after the SARP instrument is reactivated, prior to computing Doppler
solutions from SARP data. In order to mitigate the impact of SARP reactivation on Doppler
location accuracy, MCCs shall implement the following procedures.
As the MCC responsible for the SARP instrument on satellites with a Sarsat payload, the FMCC
provides notification about the reactivation of the SARP instrument. The FMCC shall provide
notification that new SARP TCAL data will be distributed, as far in advance as possible, in order
to allow adequate preparation time for each Ground Segment Provider. The notification shall be
provided in a System status message as described in Figure 5-3, and should include the time it is
expected that new SARP TCAL data will be sent to other MCCs, as available.
The FMCC shall provide new SARP TCAL data (in a SIT 415 or 417 message) as soon as reliable
SARP TCAL data is available.
When notification about new SARP TCAL data is received by the MCC, each Ground Segment
Provider shall:
a)
ensure that the calibration time (per document C/S A.002, Message Field \#37) in the new
SARP TCAL data is treated as valid in its MCC, without regard to previous SARP TCAL
data. The Ultra-Stable Oscillator (USO) frequency (C/S A.002, Message Field \#38) shall be
validated per normal procedures;
b)
ensure that the new SARP TCAL data (validated as noted above) is used to initialise the
SARP TCAL data in its LEOLUTs, without regard to previous SARP TCAL data; and
c)
ensure that all Doppler solutions generated by its LEOLUT(s) that contain SARP data for
the associated satellite are filtered, until new SARP TCAL data is loaded into the associated
LEOLUT.
Once new SARP TCAL data is processed by MCCs and LUTs, each Ground Segment Provider
shall resume normal validation of SARP TCAL data for the satellite, unless contrary notification
is received from the FMCC.
3.6.7
Space Segment Anomaly Reporting Procedures
Any Ground Segment Provider which detects anomalies of the Space Segment during routine
system monitoring, shall inform the relevant Space Segment Provider so that special tests can be
conducted, and appropriate notification can be provided. Analysis of Space Segment anomalies
shall be coordinated among the relevant Space Segment Providers and possible corrective action
(e.g., switch to backup payload) will be taken, as appropriate.

3-26

Information on any anomalies which could significantly degrade system performance shall be
provided by the MCC associated with the relevant Space Segment Provider:
a)
in a System status message as described in Figure 5-4; and
b)
to the Secretariat.
The MCC associated with the relevant Space Segment Provider shall provide status updates on
spacecraft anomalies at least once per week until the anomaly ends, or its effects are mitigated.
Further information on Space Segment Status Reporting Procedures is provided in documents
C/S T.004, C/S T.013 and C/S T.017.
3.7
Contingency Procedures
3.7.1
Operational Backup
In general, each LUT and MCC tests itself and notifies the operator of an improper condition.
Should the equipment become non-operational, the responsible MCC will notify other MCCs as
described in section 3.6 by the best means available. Alternative MCCs and communication links
could be designated for routing message traffic and assuming some of the functions of the non-
operational MCC, in accordance with predetermined backup procedures described in section 5.3
or following direct coordination with other relevant MCCs.
The MCC serving as the backup MCC may support the RCCs/SPOCs of the non-operational MCC
directly, or by routing message traffic to a SAR authority nominated by the non-operational MCC.
Non-operational MCCs should recognize the additional workload placed on the backup MCC and
provide all possible support when operating in the contingency scenario.
When an MCC assumes backup for another MCC, it shall send notification to each destination
(i.e., MCC, RCC/SPOC and SAR authority) for which it will deliver alert data directly on behalf
of the MCC being backed up.
A SIT 605 message shall be sent to all MCCs by the MCC providing the backup in accordance
with Tables 3-2 and 4-1, or should be notified using backup arrangements specific to an MCC as
provided in section 5.3. It is recommended that the end of a backup period should be notified by
both concerned MCCs, the MCC which was nonoperational and the MCC performing the backup,
using a SIT 605 message sent to all MCCs, according to Tables 3-2 and 4-1, or should be notified
according to a particular backup arrangement (section 5.3).
To ensure that the communication link to the destination is working successfully, this notification
shall:
a)
be sent by the communication link that will be used to deliver alert data; and
b)
include a request for acknowledgement, if the communication link to the destination has not
been successfully used in the last six (6) hours.

3-27

Backup procedures for the distribution of System information and alert data should be described
for each MCC in the relevant part of section 5.3. Any MCC may also communicate directly with
any other MCC and an MCC shall respond to direct requests for information.
During backup conditions MCCs may redirect message traffic to the backup MCC without
effecting any change to the SIT destination, i.e., Message Field \#5 per document C/S A.002. Each
MCC is to specify their redirection capability in its backup procedures. MCCs shall not transmit
QMS data to the backup nodal MCC.
An MCC that has assumed backup responsibilities for another MCC shall initiate and distribute
all alert messages to the appropriate destinations on behalf of the MCC being backed up, including
ship security alerts, NOCRs, alerts for RLS capable beacons and alerts for ELT(DT)s.
When an MCC that originates System data (e.g., the USMCC originates orbit data) is not
operational, the MCC that backs up the non-operational MCC is not expected to originate the
system data, unless this capability is identified in the published backup procedure. In addition,
requests for beacon registration data should be made directly of the non-operational MCC and not
the backup MCC.
3.7.2
Backup Test
Annually, each MCC should arrange to test its backup procedures. This test should include the
exercise of each specific action listed in the backup procedures and agreements section described
in section 5.3 to this DDP. This test should be performed in one single period of time. To properly
test the backup procedure, the backed up MCC shall not send data to other MCCs during the annual
backup test. Each MCC should review the results of the testing, and document problems for
corrective action. To ensure that the backup testing does not impact operational activity within a
DDR, each nodal MCC should co-ordinate backup testing within its DDR. Each MCC should also
report the backup test results to the Cospas-Sarsat Secretariat as part of their annual report on
System Status and Operations (as described in document C/S A.003). In addition, each MCC
should perform a quarterly test of all backup communication methods. Each MCC should review
the results of the tests and document problems for corrective action.
The annual backup test will not be required if the backup procedure has been successfully
exercised for a period of time not less than six (6) hours during the year prior to the planned annual
test, taking care to ensure that no more than one year passes between the tests. The backup test
will take place for at least six (6) hours to ensure the Cospas-Sarsat Quality Management System
objectives of providing timely and accurate alert data are met. Longer backup periods may be
agreed bilaterally and described in the backup procedures and agreements part of section 5.3 to
this DDP. A specific mention of this operational backup shall be noted in the annual status report.
A scheduled operational backup period may be extended with a planned backup test to create a
single continuous backup period of at least six (6) hours.
The backup test between nodal MCCs should be conducted on a “no notice” basis, that is to say,
no notification will be sent to non-nodal MCCs prior to the commencement of the test, in order to

3-28

check the real-time reconfiguration ability and replicate as much as possible a real-world scenario.
The affected MCCs shall send a confirmation narrative message to the backup nodal MCC after
reconfiguration. Administrators for affected MCCs may be notified prior to the commencement of
the test, on a bilateral basis, in order to ensure that the test has maximum effectiveness.
The quarterly communication test shall also be considered to be accomplished when the backup
procedure has been exercised during the quarter for a time period which meets the needs of the
specific MCC operator.
3.7.3
Backup Timing
When an MCC is found to be unable to operate within the specifications of this document and of
the MCC Specification and Design Guidelines (document C/S A.005), arrangements shall be made
to switch the services from the failed MCC to a backup system, according to the backup procedures
for the failed MCC, as described in the relevant part of section 5.3. The timing of the switch to the
backup system should be planned to ensure that the system will meet the requirement of the
Cospas-Sarsat Programme Management Policy (document C/S P.011) that “the capability of an
MCC to continuously deliver alert messages shall not be interrupted for longer than one hour”.
To meet this goal, the MCC operators shall, during the initial MCC testing or during subsequent
tests of backup procedures, make note of the time required for the backup to take effect. The
backup procedures shall then be established to ensure that, when an actual failure occurs, the
backup arrangements shall be initiated early enough that the backup facility is expected to take
over the service from the failed MCC within one hour of the original failure.
When an MCC is to be shut down for scheduled maintenance that is expected to last for more than
one hour, the backup arrangements should be initiated before the MCC is shut down.
3.7.4
Long-term Backup and Restoration of Operations
3.7.4.1 Long-term Backup and Restoration of MCC Operations
This section summarizes the sequence of actions to handle a long-term MCC outage and to restore
MCC operations.
When an MCC has been non-operational for an extended period of time as described in document
C/S A.003 (“Procedure for Determining the Status of Operational Ground Segment Equipment”)
the MCC status is considered to be “commissioned, not operational” (CNO).
When an MCC is set to CNO status, the associated nodal MCC shall prepare a plan for the re-
assignment of MCC responsibilities. If the MCC has remained non-operational for another 45
days, the associated nodal MCC shall coordinate the distribution of alert data to the SPOCs that
were served by the CNO MCC. If the associated nodal MCC is notified that an outage is expected

3-29

to exceed 90 days, the associated nodal MCC shall coordinate the distribution of alert data to the
SPOCs that were served by the CNO MCC as soon as possible. The sequence of events will be:
Day 0
Failure of the MCC is detected
Day 0-1
Routine backup arrangements are put in place
Day 2-45
The associated nodal MCC is notified that this is a long-term issue
Day 45\*
The associated nodal MCC notifies all MCCs and the Secretariat of the
CNO status, and that it is preparing a plan for the re-assignment of
responsibilities
Day 90\*
The nodal MCC coordinates the implementation of the alternate data
distribution plan
Note:
*  These relative days indicate a maximum period; the events may occur earlier, based on the
notification of a long-term outage.
For the purposes of this re-distribution of responsibilities, the country that operates the non-
operational MCC shall be considered as a SPOC until it has been restored to full operation. The
procedure to restore an MCC to operational status is described in the section titled “Recover
Operational Status of a CNO GSE” in document C/S A.003.
When an MCC regains FOC status, data distribution procedures affected by the loss of FOC status
shall be restored.
3.7.5
Distribution of MEOSAR Alerts to MCCs that Are Only LEOSAR/GEOSAR-
Capable
Until all LEOSAR/GEOSAR capable MCCs are commissioned as LEOSAR/GEOSAR/MEOSAR
-capable, LEOSAR/GEOSAR/MEOSAR-capable MCCs shall transmit MEOSAR alert data to
other MCCs in:
a)
a SIT 915 message with Message Field \#5 set to the identification code of the final
destination MCC, that contains alert data in SPOC format (i.e., SIT 185), if the immediate
destination MCC is LEOSAR/GEOSAR only capable; or
b)
MCC
format
(i.e.,
SITs 138 - 147),
if
the
immediate
destination
MCC
is
LEOSAR/GEOSAR/MEOSAR capable.
The format for transmitting MEOSAR alert data (SIT 915/SPOC or MCC) shall be configurable
by destination MCC. The implementation status of MEOSAR SIT messages by MCC is provided
in section 5.1.

3-30

3.7.6
Distribution of Second-Generation-Beacon (SGB) Alerts to MCCs that Are Only
First-Generation-Beacon (FGB)-Capable
Until all MCCs are SGB-capable, SGB-capable MCCs shall transmit SGB alert data to other
MCCs in:
a)
a SIT 915 message with Message Field \#5 set to the identification code of the final
destination MCC, that contains alert data in SPOC format (i.e., SIT 185), if the immediate
destination MCC is FGB-only capable and the SGB is not RLS-test protocol; or
b)
MCC format (i.e., SIT 3xx series), if the immediate destination MCC is SGB-capable.
Until all MCCs are SGB-capable, SGB-capable MCCs shall transmit a SIT 915 message (that
contains data in SIT 985 format) with Message Field \#5 set to the identification code of the final
destination MCC, if the immediate destination MCC is FGB-only-capable, as specified in section
3.2.12.
MCCs shall not distribute alerts (including NOCRs) for test coded RLS beacons to RCCs or
SPOCs, or MCCs that are not capable of processing these alerts automatically.
3.7.7
Distribution of Alerts for RLS-Capable FGBs to MCCs that Are Not FGB-RLS-
Capable
Until all MCCs are FGB-RLS-capable, FGB-RLS-capable MCCs shall transmit alert data for RLS-
capable FGBs to MCCs in:
a)
a SIT 915 message with Message Field \#5 set to the identification code of the final
destination MCC, that contains alert data in SPOC format (i.e., SIT 185), if the immediate
destination MCC is not FGB-RLS-capable and the RLS-capable FGB is not test coded; or
b)
MCC format (i.e., SIT 122 - 147), if the immediate destination MCC is FGB-RLS-capable.
MCCs shall not distribute alerts (including NOCRs) for test coded RLS beacons to RCCs or
SPOCs, or MCCs that are not capable of processing these alerts automatically.
3.7.8
Distribution of FGB-ELT(DT) Alerts to MCCs that Are Not FGB-ELT(DT)-
Capable
Until all MCCs are FGB-ELT(DT)-capable, FGB-ELT(DT)-capable MCCs shall transmit FGB-
ELT(DT) alert data to MCCs in:
a)
a SIT 915 message with Message Field \#5 set to the identification code of the final
destination MCC, that contains alert data in SPOC format (i.e., SIT 185), if the immediate
destination MCC is not FGB-ELT(DT)-capable; or
b)
MCC format (i.e., SIT 1xx series), if the immediate destination MCC is FGB-ELT(DT)-
capable.

3-31

3.7.9
Distribution of Notifications for RLS-Capable FGB Alerts to the RLSP on Behalf of
MCCs that Are Not FGB-RLS-Capable
Until all MCCs are FGB-RLS-capable, FGB-RLS-capable nodal MCCs shall transmit
notifications (i.e., SIT 134, SIT 135, SIT 138 or SIT 139) to the RLSP for an RLS-capable FGB
alert with a confirmed position regardless of whether the confirmed position is in the nodal MCC’s
service area. In addition to this modification, all other procedures in section 4.2.10 shall be applied
as defined.
3.7.10 Operational Distribution of Alert Data for SGBs
Until the Cospas-Sarsat Council declares that SGBs may be used operationally, SGB-capable
MCCs shall:
a)
be capable of being configured to filter alert data for SGBs; and
b)
be configured to filter alert data for SGBs from operational distribution.
3.7.11 Distribution of ELT(DT) Alerts to the Location of an Aircraft in Distress Repository
(LADR) on Behalf of Nodal MCCs that Are Not LADR-Capable
Until all nodal MCCs are able to send data to the LADR, the following procedure shall be applied.
Nodal MCCs that are ELT(DT)-capable but not LADR-capable shall distribute alerts and
cancellation messages for ELT(DT)s for the LADR to a nodal MCC that is LADR-capable, per
the “List of Country/Region Codes (MIDs)” Table available on the Cospas-Sarsat website. LADR-
capable nodal MCCs shall transmit alerts and confirmed cancellation messages for ELT(DT)s
received from non-LADR-capable nodal MCCs to the LADR per the “List of Country/Region
Codes (MIDs)” Table available on the Cospas-Sarsat website.
When a LADR-capable nodal MCC is offline and its back-up nodal MCC is not LADR-capable,
then the latter shall send the information to an operational LADR-capable nodal MCC (see the
"List of Country/Region Codes (MIDs)” Table available on the Cospas-Sarsat website).
3.7.12 Distribution of Alerts for TWC-Capable Beacon to MCCs that Are Not TWC-
Capable
Until all MCCs are TWC-capable, TWC-capable MCCs shall transmit alert data for TWC-capable
beacons to MCCs in:
a)
a SIT 915 message with Message Field \#5 set to the identification code of the final
destination MCC, that contains alert data in SPOC format (i.e., SIT 185 with decoded
Initial Questions and Answers (Q&As)), if the immediate destination MCC is not TWC-
capable and the TWC-capable beacon is not test coded; or
b)
MCC format (i.e., SIT 322 - 347), if the immediate destination MCC is TWC-capable.

3-32

MCCs shall not distribute alerts (including NOCRs) for test coded TWC beacons to RCCs or
SPOCs, or MCCs that are not capable of processing these alerts automatically.
3.8
Exchange of Test and Exercise Data
3.8.1
Coordination of Beacon Tests
Beacons coded with operational protocols shall not be used for tests, except on rare occasions
when required by and under control of a national administration, or for international exercises
approved by the Council, an Experts Working Group, a Task Group or the Joint Committee.
The responsible MCC shall notify affected (i.e., designated) MCCs of tests using beacons coded
with operational protocols, in accordance with the procedure of section 4.3 of the DDP.
The list of designated MCCs is provided on the Cospas-Sarsat website, based on a determination
by each MCC about whether it wishes to be informed of operational beacon tests performed in the
service area of each other MCC.
Tests using beacons coded with a Test User Protocol, may be performed by anyone having
coordinated the test with, and received approval from the responsible MCC, when conducted in
accordance with the procedure of section 4.3 of the DDP.
3.8.2
Exchange of Test Messages
Except for RLS-test protocol beacons, test data obtained for beacons coded with test protocol or
self-test mode shall be exchanged between MCCs only upon request. However, given that the
transmission of self-test data from LUTs to the associated MCC is optional, MCCs are not required
to provide test data for self-test mode transmissions.
Test data obtained for beacons coded with an operational protocol shall be processed per normal
data distribution procedures for operational beacons, unless a request is made for special
processing or data collection.
Test data obtained for beacons coded with an RLS-test-protocol shall be processed per normal data
distribution procedures for RLS-test protocol beacons, unless a request is made for special
processing or data collection.
Such requests shall contain the 15 or 23 hexadecimal characters of the Beacon Identification, as
specified in section 3.1.4. See the section entitled “Procedures for the Co-Ordination of Beacon
Tests” for more information on performing beacon tests.
3.9
Archived Information
Each LEOLUT, GEOLUT, MEOLUT and MCC shall archive alert data and other messages
transmitted, as specified in documents C/S T.002, C/S T.009, C/S T.019 and C/S A.005,
respectively.

3-33

This information will be provided upon request to another MCC, SPOC or RCC, for a specific
period of time and for activities in their area of responsibility. It may be also provided to the
Cospas-Sarsat Secretariat for the analysis of particular beacon events when such analysis has been
requested in accordance with the procedure approved by the Cospas-Sarsat Council.
3.10
Communication Networks
Each MCC transfers alert data to other MCCs and SPOCs within its service area as described in
section 5.3.
3.11
Return Link Service (RLS)
The Return Link Service (RLS) provides notification to a 406 MHz beacon that an alert transmitted
by the beacon has been detected by a LUT and distributed via the Cospas-Sarsat MCC network to
the MCC whose service area covers the confirmed position of the beacon. This service is intended
to provide acknowledgement of the reception of the alert message to persons in distress and is only
available for 406 MHz beacons coded to provide a return link.
Once notified that an RLS-capable beacon has been located, the RLSP interfaces to the ground
segment for transmitting return link messages to appropriate satellites, which, in turn, transmit
return link messages to the transmitting beacon. After receipt of the return link message by the
beacon, subsequent beacon transmissions include the return link message receipt status, and an
alert that includes the receipt status is distributed via the Cospas-Sarsat MCC network to the
designated RLSP.
Once notified that the beacon has received the return link message, the RLSP interfaces to the
relevant ground segment which will cease transmitting return link messages to satellites. Further
information on the SAR/Galileo Return Link Service is provided in the SAR/Galileo Service
Definition Document, which is available from the Galileo website (https://www.gsc-
europa.eu/galileo/services/search-and-rescue-sar-galileo-service).
The detailed procedure for the RLS processing is described in section 4.2.10.
3.12
Return Link Service – Two-Way Communication (TWC)
The Two-Way Communication (TWC) service facilitates the exchange of information between a
406-MHz distress beacon and the SAR authorities. This service is intended to provide additional
information regarding the alert and ease SAR interventions. Additional information is provided in
document C/S R.025 “Cospas-Sarsat Two-Way Communication Operational Concept and High-
Level Requirements”.
Once notified by Cospas-Sarsat that a TWC-capable beacon has been located, the SAR authority
managing the SAR case should interface with the TWC Service Provider (TWC-SP) via a web
interface or equivalent, to get additional information from the beacon user and to request the TWC
SP to disseminate information to the beacon.

3-34

The detailed procedure for the TWC processing is described in section 4.2.11 entitled “Two-Way
Communication (TWC) Procedures”.
3.13
Location of an Aircraft in Distress Repository (LADR) for ELT(DT) Alert Data
3.13.1 LADR Data Provider (LDP)
A nodal MCC is determined to be the LADR Data Provider (LDP) based on the country code of
the beacon message (see the "List of Country/Region Codes (MIDs)” Table available on the
Cospas-Sarsat website).
To provide alert data to the LADR with minimal redundancy, only the LDP shall send alerts to the
LADR.
An LDP shall be LADR-capable.
3.13.2 LADR Position Type Priority
Given that multiple position data types may be available for a single detect time (i.e., within the
same solution), and that it is necessary to select a single position for the data intended for the
LADR, the following priority order based on the type of position shall be applied:
1.
refined encoded position for an FGB or encoded position for an SGB,
2.
DOA position\*,
3.
coarse encoded position for an FGB**.
Note:  * Per section 3.2.1, MCCs shall filter all DOA position data generated by a MEOLUT for
ELT(DT)s if the MEOLUT is not commissioned to provide DOA locations for fast-moving
beacons. Doppler positions shall not be sent to the LADR.
** Only if no refined position has been previously provided.
3.13.3 Distribution by MCCs
MCCs shall provide ELT(DT) alert data intended for the LADR to their associated nodal MCC,
or to other nodal MCCs, for the LADR in SIT messages 122 to 147 and SIT messages 322 to 347,
as described in document C/S A.002. Nodal MCCs shall provide alert data to the LADR per section
“Message Content for Messages Sent to the LADR” in document C/S A.002.
3.13.3.1 LADR Responsibilities for Non-Nodal MCCs
To ensure that all pertinent ELT(DT) alert data gets to the LDP (and hence to the LADR), non-
nodal MCCs shall forward ELT(DT) alert data to their associated nodal MCC when:
a)
the new alert was generated by a LUT associated with this MCC; and
b)
the ICAO 24-bit Address for the ELT(DT) is available (from the current alert or a
previous alert); and

3-35

c)
the new alert contains unique data, defined by:
i.
the new alert is the first alert in the activation; or
ii.
the reference time (i.e., detect time) of the new alert differs by at least three (3)
seconds from the reference time of all previous alerts received; or
iii.
position data of a given type (e.g., coarse encoded, refined encoded, DOA) with a
reference time within three (3) seconds of the reference time of a previously sent
alert in the new alert has not been previously sent (i.e., matching reference time, but
the new alert contains a new type of position information); or
iv.
the new alert contains a cancellation message as specified in section 4.2.12.
3.13.3.2 LADR Responsibilities for Nodal MCCs
If a nodal MCC is not the LDP, the MCC shall send received ELT(DT) alert data to the LDP if the
new alert contains the ICAO 24-bit Address for the ELT(DT) (from the current alert or a previous
alert) and unique information, defined by:
a)
the new alert is the first alert in the activation; or
b)
the reference time (i.e., detect time) of the new alert differs by at least three (3) seconds
from the reference time of all previous alerts received; or
c)
position data of a given type (e.g., coarse encoded, refined encoded, DOA) with a
reference time within three (3) seconds of the reference time of a previously sent alert in
the new alert has not been previously sent (i.e., matching reference time, but the new alert
contains a new type of position information); or
d)
the new alert contains a cancellation message as specified in section 4.2.12.
If a nodal MCC is the LDP, the MCC shall send alert data providing a single position per section
3.12.2 and supporting data in each XML message to the LADR when:
a)
the new alert contains position data; and
b)
the Aircraft Operator Designator (3LD)* is available, and the ICAO 24-bit Address for
the ELT(DT) is available (from the current alert or a previous alert); and
c)
the new alert contains unique data, defined by:
i.
no alert has been sent to the LADR, or the reference time of the new alert differs
by at least three (3) seconds from the reference time of all previous alerts sent to
the LADR by the nodal MCC; or
ii.
the new alert contains a confirmed cancellation message as specified in section
4.2.12.
If a confirmed cancellation alert to be sent by an LDP to the LADR has no location, position data
with the latest reference time for this activation shall be included in the XML message sent to the
LADR.

3-36

In case the FGB confirmed cancellation alert message is sent to the LADR, it has to be noted that
detection time provided in the XML message corresponds to the detection time of the alert message
that confirmed the cancellation, and it is not necessarily associated with the time when the position
was produced.
In addition, the LDP shall send the previously received alert for an FGB ELT(DT) with refined
encoded position and with the most recent detect time to the LADR along with the Aircraft
Operator Designator (3LD)\*, if:
a)
the new alert message contains the Aircraft Operator Designator (3LD)* and the ICAO 24-
bit Address;
b)
no previous alert was sent to the LADR for the ELT(DT); and
c)
a previous alert for the ELT(DT) contained a refined encoded position.
If the LDP receives an alert for an FGB ELT(DT) but does not receive a beacon message
containing a 3LD within three (3) minutes after the time of receipt of the first alert, then the LDP
shall send to the LADR all alerts that were supposed to be sent initially, with the 3LD set to the
default value of “ZGA”. Until a valid encoded 3LD is received, all alerts shall be sent to the LADR
with the 3LD set to the default value of “ZGA”. If the LDP subsequently receives an alert for the
FGB ELT(DT) with a 3LD encoded in the beacon message, it shall transmit that alert (and
subsequent alerts, as required) to the LADR with the encoded 3LD.
Until the Cospas-Sarsat Council declares that ELT(DT) alert data may be sent to the LADR,
LADR-capable nodal MCCs shall be configured to not send ELT(DT) alert data to the LADR.
Note:
*  If the Aircraft Operator (3LD) is coded as “ZGA” for an FGB ELT(DT), then the Aircraft
Operator is deemed to be available in the associated beacon message field for data distribution.
– END OF SECTION 3 –

4-1

4.
OPERATIONAL PROCEDURES FOR COSPAS-SARSAT MCCs
4.1
Data Distribution Regions and Inter-MCC Data Exchange
4.1.1
Introduction
This section describes the inter-DDR arrangements for data exchange and includes the particular
regional arrangements or agreements that affect MCCs within a DDR. It may be amended by the
MCCs involved. However, other MCCs should be notified of any changes in the event that the
changes impact MCCs outside the region. If so, agreement of the Joint Committee is needed prior
to implementation.
These procedures and arrangements become effective for MCCs under development only after
confirmation by the appropriate host MCC, that the MCC under development has achieved Initial
Operational Capability (IOC).
4.1.2
Definition of DDR
A data distribution region (DDR) is a region comprising two or more MCC service areas. Cospas-
Sarsat alert data and System information are exchanged between DDRs through an MCC in each
DDR which is the single point of contact for that DDR. This MCC is identified as the nodal MCC
of the DDR.

4-2

4.1.3
Data Exchange Between DDRs
The inter-nodal network diagram is provided as Figure 4-1.
The nodes of the MCC communication network and the associated DDRs are identified as follows:
•
Australia:
AUMCC – South West Pacific DDR
•
France:
FMCC - Central DDR
•
Japan:
JAMCC – North West Pacific DDR
•
Russia:
CMC - Eastern DDR
•
Spain:
SPMCC - South Central DDR
•
USA:
USMCC - Western DDR
Figure 4-1: Inter-Nodal Network Diagram

![Image 1 from page 50](/images/cospas-sarsat/A-series/A001/A001_page_50_img_1.png)

4-3

4.1.4
Data Exchange Within DDRs
4.1.4.1 Western DDR
The USMCC, as a nodal MCC, has accepted responsibility for passing alert information in this
region and for the filtering of global mode alert or NOCR messages. Specific SRRs are outlined
in section 5.3.
Data flow in Western DDR (ARMCC, BRMCC, CHMCC, CMCC, PEMCC, and USMCC) is
described in Figure 4-2.
Figure 4-2: Western DDR Network Diagram
Central
South Central
Eastern
South  est
Pacific
North  est
Pacific
RCCs
SPOCs
RCCs
SPOCs
RCCs
SPOCs
RCCs
RCCs
RCCs
SPOCs

4-4

4.1.4.2 Central DDR
Data flow in Central DDR (CYMCC, FMCC, GRMCC, ITMCC, NMCC, TRMCC and UKMCC)
is described in Figure 4-3. Central DDR MCCs validate locations before forwarding them to the
SAR organisations.
Figure 4-3: Central DDR Network Diagram
DDR
estern
SCDDR
South Central
EDDR
Eastern
S PDDR
South  est
Pacific
N PDDR
North  est
Pacific
GRMCC
ITMCC
MCC
TRMCC
NMMCC
SPOCs
RCCs
RCCs
SPOCs
RCCs
SPOCs
RCCs
SPOCs
RCCs
FMCC
C MCC
RCCs

4-5

4.1.4.3 Eastern DDR
The CMC has no formal regional agreements.
Data flow in Eastern DDR (CMC, INMCC and PAMCC) is described in Figure 4-4.
Figure 4-4: Eastern DDR Network Diagram
CDDR
Central
SCDDR
South Central
DDR
estern
S PDDR
South  est
Pacific
N PDDR
North  est
Pacific
CMC
INMCC
PAMCC
RCCs
SPOCs
RCCs
RCCs
SPOCs

4-6

4.1.4.4 South West Pacific DDR
Data flow in South West Pacific DDR (ASMCC, AUMCC, IDMCC, MYMCC\*, SIMCC and
THMCC) is described in Figure 4-5.
*  Under development
Figure 4-5: South West Pacific DDR Network Diagram
CDDR
Central
SCDDR
South Central
EDDR
Eastern
DDR
estern
N PDDR
North  est
Pacific
A MCC
SIMCC
IDMCC
ASMCC
THMCC
M MCC
RCCs
SPOCs
RCCs
SPOCs
RCCs
SPOCs
RCCs
RCCs
RCCs
SPOCs
\*

4-7

4.1.4.5 North West Pacific DDR
Data flow in North West Pacific DDR (CNMCC, HKMCC, JAMCC, KOMCC, TAMCC and
VNMCC) is described in Figure 4-6.
Figure 4-6: North West Pacific DDR Network Diagram
CDDR
Central
SCDDR
South Central
EDDR
Eastern
S PDDR
South  est
Pacific
DDR
estern
AMCC
OMCC
H MCC
CNMCC
TAMCC
VNMCC
RCCs
RCCs
SPOCs
RCCs
RCCs
RCCs
SPOCs
RCCs

4-8

4.1.4.6 South Central DDR
Data flow in South Central DDR (AEMCC, ALMCC, NIMCC\*, QAMCC, SAMCC, SPMCC and
TGMCC**) is described in Figure 4-7.
Notes:  \*
Commissioned not operational.
**
Under development
Figure 4-7: South Central DDR Network Diagram
4.1.5
Inter-MCC Routing of Alert Data
The receiving MCC shall route alert data to the MCC in whose service area the alert is located
(i.e., the destination MCC) as described in Table 4-1.
4.1.6
Inter-MCC Routing of System Information
The routing of System information between MCCs is described in Table 4-2 “System Information
Distribution”. MCCs shall route System information as described in Table 4-1.
CDDR
Central
DDR
estern
EDDR
Eastern
S PDDR
South  est
Pacific
N PDDR
North  est
Pacific
SPMCC
NIMCC
ALMCC
AEMCC
QAMCC
SAMCC
RCCs
RCCs
SPOCs
RCCs
RCCs
RCCs
SPOCs
RCCs
SPOCs
TGMCC
RCCs
\*
**

4-9

Table 4-1: MCC Data Routing Matrix (1/2)
Receiving
MCC:
Destination MCC:
AEMCC
ALMCC
ARMCC
ASMCC
AUMCC
BRMCC
CHMCC
CMC
CMCC
CNMCC
CYMCC
FMCC
GRMCC
HKMCC
IDMCC
INMCC
ITMCC
AEMCC
Nat. Pr.
SPMCC
USMCC
AUMCC
SPMCC
USMCC
USMCC
SPMCC
USMCC
JAMCC
FMCC
SPMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
ALMCC
SPMCC
Nat. Pr.
USMCC
AUMCC
SPMCC
USMCC
USMCC
SPMCC
USMCC
JAMCC
FMCC
SPMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
ARMCC
SPMCC
SPMCC
Nat. Pr.
AUMCC
USMCC
USMCC
USMCC
USMCC
USMCC
JAMCC
FMCC
USMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
ASMCC
SPMCC
SPMCC
USMCC
Nat. Pr.
ASMCC
USMCC
USMCC
AUMCC
USMCC
JAMCC
FMCC
AUMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
AUMCC
SPMCC
SPMCC
USMCC
AUMCC
Nat. Pr.
USMCC
USMCC
AUMCC
USMCC
JAMCC
FMCC
AUMCC
FMCC
JAMCC
AUMCC
AUMCC
FMCC
BRMCC
SPMCC
SPMCC
USMCC
AUMCC
USMCC
Nat. Pr.
USMCC
USMCC
USMCC
JAMCC
FMCC
USMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
CHMCC
SPMCC
SPMCC
USMCC
AUMCC
USMCC
USMCC
Nat. Pr.
USMCC
USMCC
JAMCC
FMCC
USMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
CMC
SPMCC
SPMCC
USMCC
AUMCC
CMC
USMCC
USMCC
Nat. Pr.
USMCC
JAMCC
FMCC
CMC
FMCC
JAMCC
AUMCC
CMC
FMCC
CMCC
SPMCC
SPMCC
USMCC
AUMCC
USMCC
USMCC
USMCC
USMCC
Nat. Pr.
JAMCC
FMCC
USMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
CNMCC
SPMCC
SPMCC
USMCC
AUMCC
JAMCC
USMCC
USMCC
JAMCC
USMCC
Nat. Pr.
FMCC
JAMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
CYMCC
SPMCC
SPMCC
USMCC
AUMCC
FMCC
USMCC
USMCC
FMCC
USMCC
JAMCC
Nat. Pr.
CYMCC
CYMCC
JAMCC
AUMCC
CMC
ITMCC
FMCC
SPMCC
SPMCC
USMCC
AUMCC
FMCC
USMCC
USMCC
FMCC
USMCC
JAMCC
FMCC
Nat. Pr.
FMCC
JAMCC
AUMCC
CMC
FMCC
GRMCC
SPMCC
SPMCC
USMCC
AUMCC
FMCC
USMCC
USMCC
FMCC
USMCC
JAMCC
GRMCC
GRMCC
Nat. Pr.
JAMCC
AUMCC
CMC
GRMCC
HKMCC
SPMCC
SPMCC
USMCC
AUMCC
JAMCC
USMCC
USMCC
JAMCC
USMCC
JAMCC
FMCC
JAMCC
FMCC
Nat. Pr.
AUMCC
CMC
FMCC
IDMCC
SPMCC
SPMCC
USMCC
AUMCC
IDMCC
USMCC
USMCC
AUMCC
USMCC
JAMCC
FMCC
AUMCC
FMCC
JAMCC
Nat. Pr.
CMC
FMCC
INMCC
SPMCC
SPMCC
USMCC
AUMCC
INMCC
USMCC
USMCC
INMCC
USMCC
JAMCC
FMCC
CMC
FMCC
JAMCC
AUMCC
Nat. Pr.
FMCC
ITMCC
SPMCC
SPMCC
USMCC
AUMCC
FMCC
USMCC
USMCC
FMCC
USMCC
JAMCC
ITMCC
ITMCC
ITMCC
JAMCC
AUMCC
CMC
Nat. Pr.
JAMCC
SPMCC
SPMCC
USMCC
AUMCC
JAMCC
USMCC
USMCC
JAMCC
USMCC
JAMCC
FMCC
JAMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
KOMCC
SPMCC
SPMCC
USMCC
AUMCC
JAMCC
USMCC
USMCC
JAMCC
USMCC
JAMCC
FMCC
JAMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
MYMCC\*
SPMCC
SPMCC
USMCC
AUMCC
MYMCC
USMCC
USMCC
AUMCC
USMCC
JAMCC
FMCC
AUMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
NIMCC**
SPMCC
SPMCC
USMCC
AUMCC
SPMCC
USMCC
USMCC
SPMCC
USMCC
JAMCC
FMCC
SPMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
NMCC
SPMCC
SPMCC
USMCC
AUMCC
FMCC
USMCC
USMCC
FMCC
USMCC
JAMCC
NMCC
NMCC
NMCC
JAMCC
AUMCC
CMC
NMCC
PAMCC
SPMCC
SPMCC
USMCC
AUMCC
CMC
USMCC
USMCC
PAMCC
USMCC
JAMCC
FMCC
CMC
FMCC
JAMCC
AUMCC
CMC
FMCC
PEMCC
SPMCC
SPMCC
USMCC
AUMCC
USMCC
USMCC
USMCC
USMCC
USMCC
JAMCC
FMCC
USMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
QAMCC
SPMCC
SPMCC
USMCC
AUMCC
SPMCC
USMCC
USMCC
SPMCC
USMCC
JAMCC
FMCC
SPMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
SAMCC
SPMCC
SPMCC
USMCC
AUMCC
SPMCC
USMCC
USMCC
SPMCC
USMCC
JAMCC
FMCC
SPMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
SIMCC
SPMCC
SPMCC
USMCC
AUMCC
SIMCC
USMCC
USMCC
AUMCC
USMCC
JAMCC
FMCC
AUMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
SPMCC
SPMCC
SPMCC
USMCC
AUMCC
SPMCC
USMCC
USMCC
SPMCC
USMCC
JAMCC
FMCC
SPMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
TAMCC
SPMCC
SPMCC
USMCC
AUMCC
JAMCC
USMCC
USMCC
JAMCC
USMCC
JAMCC
FMCC
JAMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
TGMCC\*
SPMCC
SPMCC
USMCC
AUMCC
SPMCC
USMCC
USMCC
SPMCC
USMCC
JAMCC
FMCC
SPMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
THMCC
SPMCC
SPMCC
USMCC
AUMCC
THMCC
USMCC
USMCC
AUMCC
USMCC
JAMCC
FMCC
AUMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
TRMCC
SPMCC
SPMCC
USMCC
AUMCC
FMCC
USMCC
USMCC
FMCC
USMCC
JAMCC
TRMCC
TRMCC
TRMCC
JAMCC
AUMCC
CMC
TRMCC
UKMCC
SPMCC
SPMCC
USMCC
AUMCC
FMCC
USMCC
USMCC
FMCC
USMCC
JAMCC
UKMCC
UKMCC
UKMCC
JAMCC
AUMCC
CMC
UKMCC
USMCC
SPMCC
SPMCC
USMCC
AUMCC
USMCC
USMCC
USMCC
USMCC
USMCC
JAMCC
FMCC
USMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
VNMCC
SPMCC
SPMCC
USMCC
AUMCC
JAMCC
USMCC
USMCC
JAMCC
USMCC
JAMCC
FMCC
JAMCC
FMCC
JAMCC
AUMCC
CMC
FMCC

4-10

Table 4-1: MCC Data Routing Matrix (2/2)
Receiving
MCC:
Destination
MCC:
JAMCC
KOMCC
MYMCC
\*
NIMCC
**
NMCC
PAMCC
PEMCC
QAMCC
SAMCC
SIMCC
SPMCC
TAMCC
TGMCC
\*
THMCC
TRMCC
UKMCC
USMCC
VNMCC
AEMCC
SPMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
AEMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
SPMCC
JAMCC
ALMCC
SPMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
ALMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
SPMCC
JAMCC
ARMCC
USMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
USMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
ARMCC
JAMCC
ASMCC
AUMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
AUMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
AUMCC
JAMCC
AUMCC
AUMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
AUMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
AUMCC
JAMCC
BRMCC
USMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
USMCC
JAMCC
SPMCC AUMCC
FMCC.
FMCC
BRMCC
JAMCC
CHMCC
USMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
USMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
CHMCC
JAMCC
CMC
CMC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
CMC
JAMCC
SPMCC AUMCC
FMCC
FMCC
CMC
JAMCC
CMCC
USMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
USMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
CMCC
JAMCC
CNMCC
CNMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
JAMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
JAMCC
JAMCC
CYMCC
FMCC
JAMCC
AUMCC SPMCC
CYMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
FMCC
JAMCC
SPMCC AUMCC
CYMCC
CYMCC
FMCC
JAMCC
FMCC
FMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
FMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
FMCC
JAMCC
GRMCC
FMCC
JAMCC
AUMCC SPMCC
GRMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
FMCC
JAMCC
SPMCC AUMCC
GRMCC
GRMCC
FMCC
JAMCC
HKMCC
HKMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
JAMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
JAMCC
JAMCC
IDMCC
AUMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
AUMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
AUMCC
JAMCC
INMCC
CMC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
CMC
JAMCC
SPMCC AUMCC
FMCC
FMCC
CMC
JAMCC
ITMCC
FMCC
JAMCC
AUMCC SPMCC
ITMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
FMCC
JAMCC
SPMCC AUMCC
ITMCC
ITMCC
FMCC
JAMCC
JAMCC
Nat. Pr.
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
JAMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
JAMCC
JAMCC
KOMCC
KOMCC
Nat. Pr.
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
JAMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
JAMCC
JAMCC
MYMCC\*
AUMCC
JAMCC
Nat. Pr.
SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
AUMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
AUMCC
JAMCC
NIMCC**
SPMCC
JAMCC
AUMCC Nat. Pr.
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
NIMCC**
JAMCC
SPMCC AUMCC
FMCC
FMCC
SPMCC
JAMCC
NMCC
FMCC
JAMCC
AUMCC SPMCC
Nat. Pr.
CMC
USMCC
SPMCC
SPMCC
AUMCC
FMCC
JAMCC
SPMCC AUMCC
NMCC
NMCC
FMCC
JAMCC
PAMCC
CMC
JAMCC
AUMCC SPMCC
FMCC
Nat. Pr.
USMCC
SPMCC
SPMCC
AUMCC
CMC
JAMCC
SPMCC AUMCC
FMCC
FMCC
CMC
JAMCC
PEMCC
USMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
Nat. Pr.
SPMCC
SPMCC
AUMCC
USMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
PEMCC
JAMCC
QAMCC
SPMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
Nat. Pr.
SPMCC
AUMCC
QAMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
SPMCC
JAMCC
SAMCC
SPMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
Nat. Pr.
AUMCC
SAMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
SPMCC
JAMCC
SIMCC
AUMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
Nat. Pr.
AUMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
AUMCC
JAMCC
SPMCC
SPMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
Nat. Pr.
JAMCC
SPMCC AUMCC
FMCC
FMCC
SPMCC
JAMCC
TAMCC
TAMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
JAMCC
Nat. Pr.
SPMCC AUMCC
FMCC
FMCC
JAMCC
JAMCC
TGMCC\*
SPMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
TGMCC
JAMCC
Nat.PR. AUMCC
FMCC
FMCC
SPMCC
JAMCC
THMCC
AUMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
AUMCC
JAMCC
SPMCC Nat. Pr.
FMCC
FMCC
AUMCC
JAMCC
TRMCC
FMCC
JAMCC
AUMCC SPMCC
TRMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
FMCC
JAMCC
SPMCC AUMCC
Nat. Pr.
TRMCC
FMCC
JAMCC
UKMCC
FMCC
JAMCC
AUMCC SPMCC
UKMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
FMCC
JAMCC
SPMCC AUMCC
UKMCC
Nat. Pr.
FMCC
JAMCC
USMCC
USMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
USMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
Nat. Pr.
JAMCC
VNMCC
VNMCC
JAMCC
AUMCC SPMCC
FMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
JAMCC
JAMCC
SPMCC AUMCC
FMCC
FMCC
JAMCC
Nat. Pr.
Notes:
Nat. Pr.
National Procedures.
\*
Under development. To be implemented when the DMCC is declared operating at IOC
**
Commissioned not operational

4-11

Table 4-2: System Information Distribution (1/4)
Transmitting
MCC
AEMCC
ALMCC
ARMCC
ASMCC
AUMCC
BRMCC
CHMCC
CMC
CMCC
CNMCC
CYMCC
FMCC
GRMCC
HKMCC
IDMCC
INMCC
ITMCC
System
Information
Sarsat, GPS/DASS
Spacecraft &
Ephemeris
Data***
LUTs
LUTs
LUTs
LUTs
ASMCC
LUTs
LUTs
INMCC
LUTs
LUTs
LUTs
CYMCC
LUTs
LUTs
LUTs
LUTs
LUTs
IDMCC
PAMCC
ITMCC
MYMCC\*
LUTs
GRMCC
SIMCC
NMCC
THMCC
TRMCC
LUTs
UKMCC
LUTs
Cospas, Glonass
Spacecraft &
Ephemeris
Data***
LUTs
LUTs
LUTs
LUTs
ASMCC
LUTs
LUTs
AUMCC
LUTs
LUTs
LUTs
CYMCC
LUTs
LUTs
LUTs
LUTs
LUTs
IDMCC
FMCC
ITMCC
MYMCC\*
INMCC
GRMCC
SIMCC
JAMCC
NMCC
THMCC
PAMCC
TRMCC
LUTs
SPMCC
UKMCC
USMCC
LUTs
LUTs
Sarsat SARP Time
Calibration***,
Galileo Spacecraft
& Ephemeris Data
LUTs
LUTs
LUTs
LUTs
ASMCC
LUTs
LUTs
INMCC
LUTs
LUTs
LUTs
AUMCC
LUTs
LUTs
LUTs
LUTs
LUTs
IDMCC
PAMCC
CMC
MYMCC\*
LUTs
CYMCC
SIMCC
GRMCC
THMCC
ITMCC
LUTs
JAMCC
NMCC
SPMCC
TRMCC
UKMCC
USMCC
LUTs
BDS Spacecraft &
Ephemeris Data
ASMCC
INMCC
JAMCC
CYMCC
IDMCC
PAMCC
TBD
ITMCC
MYMCC\*
GRMCC
SIMCC
NMCC
THMCC
TRMCC
UKMCC

4-12

Table 4-2: System Information Distribution (2/4)
Transmitting
MCC
AEMCC
ALMCC
ARMCC
ASMCC
AUMCC
BRMCC
CHMCC
CMC
CMCC
CNMCC
CYMCC
FMCC
GRMCC
HKMCC
IDMCC
INMCC
ITMCC
System
Information
SARP Commands
USMCC
SARP Cmd
Response &
Housekeeping
SARR Commands
USMCC
SARR Cmd
Response &
Housekeeping
System Status
SPMCC
SPMCC
USMCC
AUMCC
ASMCC
USMCC
USMCC
AUMCC
USMCC
JAMCC
FMCC
AUMCC
FMCC
JAMCC
AUMCC
CMC
FMCC
CMC
FMCC
CMC
FMCC
INMCC
CYMCC
JAMCC
JAMCC
GRMCC
IDMCC
PAMCC
ITMCC
MYMCC\*
SPMCC
JAMCC
SIMCC
USMCC
NMCC
SPMCC
SPMCC
THMCC
TRMCC
USMCC
UKMCC
USMCC
406 MHz SARR
Frequency
Calibration
USMCC

4-13

Table 4-2: System Information Distribution (3/4)
Transmitting MCC
JAMCC
KOMCC
MYMCC
\*
NIMCC
**
NMCC
PAMCC
PEMCC
SAMCC
QAMCC
SIMCC
SPMCC
TAMCC
TGMCC
\*
THMCC
TRMCC
UKMCC
USMCC
VNMCC
System
Information
Sarsat, GPS/DASS
Spacecraft &
Ephemeris
Data***
CNMCC
LUTs
LUTs
LUTs
LUTs
LUTs
LUTs
LUTs
LUTs
LUTs
AEMCC
LUTs
LUTs
LUTs
LUTs
LUTs
ARMCC
LUTs
HKMCC
ALMCC
AUMCC
KOMCC
NIMCC**
BRMCC
TAMCC
QAMCC
CHMCC
VNMCC
SAMCC
CMC
LUTs
TGMCC\*
CMCC
LUTs
FMCC
JAMCC
SPMCC
PEMCC
LUTs
Cospas, Glonass
Spacecraft &
Ephemeris
Data***
CNMCC
LUTs
LUTs
LUTs
LUTs
LUTs
LUTs
LUTs
LUTs
LUTs
AEMCC
LUTs
LUTs
LUTs
LUTs
LUTs
ARMCC
LUTs
HKMCC
ALMCC
AUMCC
KOMCC
NIMCC**
BRMCC
TAMCC
QAMCC
CHMCC
VNMCC
SAMCC
CMCC
LUTs
TGMCC\*
PEMCC
LUTs
LUTs
Sarsat SARP Time
Calibration***,
Galileo Spacecraft
& Ephemeris Data
CNMCC
LUTs
LUTS
LUTs
LUTs
LUTs
LUTs
LUTs
LUTs
LUTs
AEMCC
LUTs
LUTs
LUTs
LUTs
LUTs
ARMCC
LUTs
HKMCC
ALMCC
BRMCC
KOMCC
NIMCC**
CHMCC
TAMCC
QAMCC
CMCC
VNMCC
SAMCC
PEMCC
LUTs
TGMCC\*
LUTs
LUTs
BDS Spacecraft &
Ephemeris Data
AUMCC
AEMCC
ARMCC
CMC
ALMCC
BRMCC
FMCC
NIMCC**
CHMCC
HKMCC
QAMCC
CMCC
KOMCC
SAMCC
PEMCC
SPMCC
TGMCC\*
TAMCC
USMCC
VNMCC

4-14

Table 4-2: System Information Distribution (4/4)
Transmitting MCC
JAMCC
KOMCC
MYMCC
\*
NIMCC**
NMCC
PAMCC
PEMCC
SAMCC
QAMCC
SIMCC
SPMCC
TAMCC
TGMCC
\*/
THMCC
TRMCC
UKMCC
USMCC
VNMCC
System Information
SARR Commands
NOAA
SARP Cmd Response
& Housekeeping
FMCC
SARR Commands
USMCC
NOAA
SARR Cmd
Response &
Housekeeping
CMCC
System Status
AUMCC
JAMCC
AUMCC
SPMCC
CMC
USMCC
SPMCC
SPMCC
AUMCC
JAMCC
AEMCC
JAMCC
SPMCC
AUMCC
FMCC
FMCC
ARMCC
JAMCC
CNMCC
ALMCC
AUMCC
CMC
AUMCC
BRMCC
FMCC
CMC
CHMCC
HKMCC
FMCC
CMC
KOMCC
JAMCC
CMCC
TAMCC
NIMCC**
FMCC
USMCC
QAMCC
JAMCC
VNMCC
SAMCC
PEMCC
SPMCC
TGMCC\*
SPMCC
USMCC
406 MHz SARR
Frequency
Calibration
Notes:
\*
Under development.
**
Commissioned not operational.
***  Sarsat and Cospas ephemeris data and Sarsat SARP Time Calibration are distributed to LEOLUTs.

4-15

4.2
Detailed Implementation of Data Distribution Procedures
The following sections provide detailed implementation information on selected data distribution
procedures and requirements. These procedures are agreed by the Joint Committee and apply to
all MCCs unless otherwise stated.
4.2.1
Alert Message Validation (Filtering Anomalous Data)
Alert message validation should be performed at each MCC to prevent incorrect data from being
transmitted to other MCCs and Distress authorities. The flowchart (Figure 4-8) is provided to
illustrate data validation procedures for ease of comprehension, given the complexity of the
validation process. The flowchart is intended to clarify data validation procedures and incorporates
all the validation requirements of section 4.2. It is not intended to replace the detailed requirements
provided in the remainder of section 4.2. The associated alert message validation table
(Table 4-3) follows the logic of the flowchart and includes the same decision diamonds.
4.2.1.1 Validation of Alert Message Format and Content
Each MCC should validate all incoming beacon alert messages based on the format and content of
the SIT message.
4.2.1.1.1
Validation of SIT Message Format
The format of a SIT message should be deemed corrupt if:
a)
any message field is missing; or
b)
the size of any message field is incorrect; or
c)
a numeric message field contains non-numeric character(s); or
d)
a space or decimal point is incorrectly placed.
The resultant MCC action is defined by Table 4-3.

4-16

Pass
SIT Format?
Table II/B.1
[SF]
Pass Message
Field?
Table II/B.3
[MF]
Yes
Suppress
[BOX # 00]
No
Frame Sync valid?
Sec. II/B.1.1.3
[FS]
Yes
Dop/DOA
Information
Available?
Yes
D = FALSE
No
D = TRUE
Yes
Number of
Uncorrected BCH-1
errors =0?
Table II/B.4
[BCH-1]
D = TRUE?
[D]
No
Beacon ID
matches previous
valid Beacon ID
\*
Yes
Distribute based on valid Beacon ID
and
Doppler/DOA Location data
[BOX # 14]
Yes
Distribute based on Doppler/DOA Location only
\*
[BOX # 01]
No
Pass Protocol
Validation?
Table II/B.4
[PV]
Yes
Long
Format
Message?
[F]
Yes
PDF-2 is Not
Truncated?
[PDF-2]
Yes
Number of
uncorrected
BCH-2 errors = 0
[BCH-2]
Yes
Encoded
Location Data
Available in PDF-1?
[EP]
No
No
Encoded
LocAtion
Data inside
Sat Footprint?
Sec II/B.1.4
[EF]
Yes
D = TRUE?
[D]
No
Process Based Upon Dop/DOA Locations & Short
Message Data except Encoded Position
[BOX # 05]
Yes
Process Based Upon Short
Message Data except
Encoded Position
[BOX # 04]
No
D = TRUE?
[D]
Process based upon Short
Message Data
[BOX # 02]
No
Process Based Upon Short
Message Data & Dop/DOA
Locations
[BOX # 03]
Yes
Encoded
Location Data
Available in PDF-1?
[EP]
No
D = TRUE?
[D]
No
Encoded
Location
Data inside
Sat Footprint?
Sec III/B.1.4
[EF]
Yes
D = TRUE?
[D]
No
Process Based Upon Dop/
DOA Locations & PDF-1
Message Data except
Encoded Position
[BOX # 09]
Yes
Process Based Upon
PDF-1 Message Data
except Encoded Position
[BOX # 08]
No
Process based upon PDF-1
Message Data
[BOX # 06]
No
Process Based Upon PDF-1
Message Data & Dop/DOA
Locations
[BOX # 07]
Yes
Encoded
Location Data
Available
in Complete
Message?
[EP]
Yes
Encoded
Location
Data inside
Sat Footprint?
Sec II/B.1.4
[EF]
Yes
D = TRUE?
[D]
No
Process Based Upon Dop/
DOA Locations & Long
Message Data except
Encoded Position
[BOX # 13]
Yes
Process Based Long
Message Data except
Encoded Position
[BOX # 12]
No
D = TRUE?
[D]
No
Process Based Upon Long
Message Data
[BOX # 10]
No
Process Based Upon Long
Message Data & Dop/DOA
Locations
[BOX # 11]
Yes
Yes
No
No
No
No
No
Yes
Incoming 406 MHz Beacon
Message
Yes
* The matching process shall be based on bits 26 to 85 of the 406
MHz Beacon Message with no bits defaulted. No other
processing shall be based on any portion of the Beacon Message.
Figure 4-8: 406 MHz Alert Message Validation Flowchart
Note:  « Dop/DOA» denotes Doppler/DOA. MEOSAR uncorroborated alerts are processed per section 4.2.1.4
Pass
SIT Format?
Table 4-3
[SF]
Pass Message
Field?
Table 4-5
[MF]
Frame Sync
Valid?
Sec. 4.2.1.1.3
[FS]
Number of
Uncorrected
BCH-1 errors=0?
Table 4-6
[BCH-1]
Pass Protocol
Validation?
Table 4-6
[PV]
Encoded
Location Data
inside Sat
Footprint?
Sec. 4.2.3
[EF]
Encoded
Location
Data inside
Sat Footprint?
Sec. 4.2.3
[EF]

![Image 1 from page 64](/images/cospas-sarsat/A-series/A001/A001_page_64_img_1.png)

![Image 2 from page 64](/images/cospas-sarsat/A-series/A001/A001_page_64_img_2.png)

![Image 3 from page 64](/images/cospas-sarsat/A-series/A001/A001_page_64_img_3.png)

![Image 4 from page 64](/images/cospas-sarsat/A-series/A001/A001_page_64_img_4.png)

![Image 5 from page 64](/images/cospas-sarsat/A-series/A001/A001_page_64_img_5.png)

![Image 6 from page 64](/images/cospas-sarsat/A-series/A001/A001_page_64_img_6.png)

4-17

Table 4-3: MCC Action Based on SIT Format
SIT Format
Action
Corrupt
Suppress
Not Corrupt
See Table 4-4
Table 4-4: 406 MHz Alert Message Validation


SF
MF
FS
BCH-1
PV
PrVal
F
PDF-2
BCH-2
EP
EF
D
BOX


Legend –  Flowchart abbreviation equivalence follows. Text within <“...”> (e.g., <“Pass SIT Format?
Table 4-3”>) refers to the equivalent decision diamond in the flowchart.
SF:
<“Pass SIT Format? Table 4-3”>: (0= No / 1=Yes).
MF:
<“Pass Message Field? Table 4-4”>: (0=No / 1=Yes).
FS:
<“Frame Sync valid? Section 4.2.1.1.3”>: (0=No / 1=Yes). Set to 1 for SGB.
BCH-1:
<“Number of Uncorrected BCH-1 errors=0? Table 4-5”>: (0=No /1=Yes).
PV:
<“Protocol Validation. Table 4-6”>: (0=Fail / 1=Pass).
PrVal:
<“Beacon ID matches previous valid beacon ID”>: (0=No / 1=Yes).

4-18

F:
<“Long Format?”>: (0=Short / 1=Long). Set to 0 for SGB.
PDF-2:
<“PDF-2 is Not Truncated?”>: (0=No / 1=Yes). Set to 0 for SGB.
BCH-2:
<“Number of uncorrected BCH-2 errors=0?”>: (0=No / 1=Yes). Not applicable for SGB.
EP:
<“Encoded Position Available?”>: (0=No / 1=Yes).
EF:
<“Encoded Location in Footprint?”>: (0=No / 1=Yes).
D:
<“Doppler/DOA Locations Used?”>, i.e., <“D=TR E?”>: (0 =No / 1=Yes). No, if Doppler
for SGB; otherwise, Yes for Doppler/DOA location.
Note:
If a test is irrelevant in a particular context (e.g., the BCH-2 test for Short Format Messages [F=0])
then the cell in the table is shaded.
4.2.1.1.2
Validation of SIT Message Field Content
Some message fields are essential to MCC alert processing. MCCs shall validate SIT message
fields, against allowable values in document C/S A.002 Table “Message Fields Description”, as
specified in Table 4-5.
Table 4-5: MCC Action Based on Message Field Content
Message Field \#
Data Contents
(According to C/S A.002,
Table B.1)
In Range
Out of Range
2, 4, 6, 8, 10, 11, 12, 13, 14, 14a, 14b, 21, 23,
25, 26, 27, 31, 77, 83, and 90
Process
Suppress
Other SIT Message Fields
Process
Process
Alert messages shall not be suppressed based on out-of-range values unless the message field is
contained in the above list.
4.2.1.1.3
406 MHz Beacon Message Validation
Normal mode FGB messages have a perfect match of bits 16 to 24 with the 9-bit frame
synchronization pattern described in document C/S T.001. If bits 16 to 24 of the FGB message (as
contained in Message Field \#77) do not perfectly match the 9-bit frame synchronization pattern
(000101111), then the MCC shall suppress the associated MEOSAR alert. If an SGB alert is a self-
test transmission (per Message Field \#90), then the MCC shall suppress the associated alert, except
for the distribution of the alert to the associated nodal MCC for a designated QMS reference
beacon.
In addition to the above validation, each MCC shall perform a BCH check of all incoming
406 MHz alert FGB messages from MCCs and LUTs to ensure that the 406 MHz beacon message
(Message Field \#23) is valid.
In addition, when the first protected field of the FGB or SGB message has no uncorrected BCH
errors, each MCC shall validate the beacon message contents against specified values for FGBs
per document C/S T.001 and SGBs per document C/S T.018, in accordance with Table 4-6.

4-19

A 406 MHz beacon alert message fails when one or more of the conditions in Table 4-6 below are
met.
Table 4-6: Protocol Validation for 406 MHz Alert Messages
Beacon Type
Item to Check
Bits
Fail if:
FGB
Country code not
allocated
27 - 36
Decimal value < 200 or > 987 or
not allocated between 200 and 987**
FGB
User Protocol
37 - 39
Bit 26 = 1, and
Bits 37 - 39 = 101
FGB
Serial User Protocol
40 - 42
Bit 26 = 1, and
Bits 40 - 42 = 101 or 111
FGB
Short Format Location
Protocol
25 - 26
Bit 25 = 0, and
Bit 26 = 0
FGB
Standard Location Ship
Security Protocol
61 - 64
Bit 25 = 1 and bit 26 = 0, and
Bits 37 - 40 = 1100, and bits 61 - 64  0000
FGB
Return Link Service
Location Protocol
(only for the non MMSI
Protocol)
43 - 52
Bit 25 = 1 and bit 26 = 0, and
Bits 37 - 40 = 1101, and
Bits 43 – 46  1111, and
decimal value < 1 or (> 949 and < 960)
FGB
ELT(DT) Location
Protocol
41 - 42
Bit 25 = 1 and bit 26 = 0, and
Bits 37 - 40 = 1001, and
Bits 41 – 42 = 11
FGB
Maritime User or Radio
Call Sign
82 - 83
Bit 26 = 1, and
Bits 37 - 39 = 010 or 110, and
Bits 82 - 83 are non-zero
FGB
Unallocated Location
Protocols
37 - 40
Bit 26 = 0, and
Bits 37 - 40 = 0000 or 0001
FGB
Supplementary data
(Standard Location
Protocols)
107 - 110
Bit 26 = 0, and
Bits 37 - 40 = 0010, 0011, 0100, 0101, 0110, 0111
1110, and
Bits 107 - 110  1101
FGB
Supplementary data
(Standard Location Ship
Security Protocol)
107 - 110
Bit 25 = 1 and bit 26 = 0, and
Bits 37 - 40 = 1100, and
Bits 107 - 110  1101
FGB
Supplementary data
(National Location
Protocol, Long)
107 - 109
Bit 25 = 1 and bit 26 = 0, and
Bits 37 - 40 = 1000, 1010, 1011 or 1111, and
Bits 107 - 109  110
FGB
Supplementary data
(ELT(DT) Location
Protocol)
107 - 108
Bit 25 = 1 and bit 26 = 0, and
Bits 37 – 40 = 1001, and
Bits 107 - 108 = 11
FGB
Supplementary data
(ELT(DT) Location
Protocol when the
cancellation message bit
sequence is not present)
115 – 117
Bit 25 = 1 and bit 26 = 0, and
Bits 37 – 40 = 1001, and
Bits 113 – 114 = 00 and bits 115 – 117  000
FGB, SGB
Modified Baudot code
Varies
Unassigned Baudot character (many cases, including
the Modified Baudot code in bits 118 – 132 for an

4-20

Beacon Type
Item to Check
Bits
Fail if:
FGB when bit 25 = 1 and bit 26 = 0, and bits 37 – 40 =
1001, and bits 113 – 114 = 00, and bits 115 – 117 =
000)
FGB, SGB
Binary-coded decimal
Varies
Decimal value for four-bit group > 10, where 10 (bit
value 1010) indicates a “space” character
FGB, SGB
Encoded Latitude and
Longitude
Varies
Encoded Latitude > 90 or
Encoded Longitude > 180
For FGBs:
1- the check is performed after any usable encoded
position data in PDF-2 (Bits 107 – 144) is included in
the encoded position;
2- Additionally, for FGB ELT(DT)s, this check is
performed if, and only if, the PDF-1 is not encoded
with the cancellation bit pattern.
SGB
Country code not
allocated
31 - 40*
Decimal value < 200 or > 987 or
not allocated between 200 and 987**
SGB
Aircraft / Vessel ID type
91 - 93*
Bits 91 - 93 = 110
SGB
Aircraft / Vessel ID type
91 – 93\*
Bit 43 = 0 and bits 91 – 93 = 111
SGB
Aircraft / Vessel ID
94 – 137\*
Bits 91 – 93 = 010 and bits 136 – 137  00,
Bits 91 – 93 = 011 and bits 136 – 137  00,
Bits 91 – 93 = 100 and bits 118 – 137 are non-zero and
(bits 118 – 132 contain an invalid Modified Baudot
code, or bits 133 – 137 are non-zero), or
bits 91 – 93 = 101 and (bits 94 – 108 contain an invalid
Modified Baudot code, or bits 109 – 120 are zero or
bits 121 – 137 are non-one)
SGB
Beacon Type

140\*
Bits 138 – 140 = 100, 101, 110, or
Bits 138 – 140 = 111 and bit 43 = 0
SGB
Spare bits and rotating
field fixed bits

200\*
Bits 155 – 158 = 1111 and either:
Bits 141 – 154 are non-zero, or
Bits 159 – 200 are non-one
Notes:
\*
Based on the 154-bit main data field, and 48-bit rotating field, per C/S T.018 section 3.
**
Validation performed based on the Cospas-Sarsat website “List of Country/Region Codes
(MIDs)”. The  SMCC originates notification of new Country/Region Codes in a System
Status message, based on information published by ITU, or derived from ITU
recommendations.
Determination of Country Code for Beacons with Country Codes That Appear to Be Below
“200” or  bove “780”:
For beacons with a country code of “111” (FGB bits 27-36 or SGB bits 31-40) the following
applies:
a)
For FGBs coded with either the Maritime User Protocol, Standard Location EPIRB MMSI
Protocol or the RLS MMSI Location Protocol, the actual country code to be used for data

4-21

distribution shall be the first three digits of the decoded six-digit truncated MMSI. That is,
if the full 9-digit MMSI (formed by appending the six-digit truncated MMSI to the country
code) is 111MIDXXX, then digits 4, 5 and 6 (“MID”) form the country code.
b)
For SGBs coded with the Maritime MMSI:
i.
if the 9-digit MMSI in bits 94-123 is of the form 111MIDXXX, then digits 4, 5 and 6
(“MID”) form the country code to be used for data distribution; however
ii.
if bits 94-123 are of the form MIDXXXXXX where the first 3-digits (“MID”) form a
country code between “200” and “780”, then digits 1, 2 and 3 (“MID”) form the
country code to be used for data distribution.
For beacons with a country code of “982” to “987” (FGB bits 27-36 or SGB bits 31-40) the
following applies:
a)
For FGBs coded with either the Maritime User Protocol, Standard Location EPIRB MMSI
Protocol or the RLS MMSI Location Protocol, the actual country code to be used for data
distribution shall be the third digit of the country code combined with the first two digits of
the decoded six-digit truncated MMSI. That is if the full 9-digit MMSI is of the form
98MIDXXXX, then digits 3, 4 and 5 (“MID”) form the country code.
b)
For SGBs coded with the Maritime MMSI:
i.
if the 9-digit MMSI in bits 94-123 is of the form 98MIDXXXX, then digits 3, 4 and 5
(“MID”) form the country code to be used for data distribution; however
ii.
if bits 94-123 are of the form MIDXXXXXX where the first 3 digits (“MID”) form a
country code between “200” and “780”, then digits 1, 2 and 3 (“MID”) form the
country code to be used for data distribution.
For beacons with a country code of “970”, “972”, “974” or “979” (FGB bits 27-36 or SGB bits
31-40) the following applies:
a)
For FGBs coded with either the Maritime User Protocol, Standard Location EPIRB MMSI
Protocol or the RLS MMSI Location Protocol, it is not possible to determine the country of
registration from these types of MMSI. Therefore, without further information it is not
possible to determine a country code to be used for data distribution. Alerts from beacons
with these country codes can only be distributed to the SAR authorities as determined by the
beacon location.
b)
For SGBs coded with the Maritime MMSI:
i.
if the 9-digit MMSI in bits 94-123 is of the form 97AXXYYYY, it is not possible to
determine the country of registration from these types of MMSI. Therefore, without
further information, it is not possible to determine a country code to be used for data
distribution. Alerts from beacons with these country codes can only be distributed to
SAR authorities as determined by the beacon location; however,
ii.
if bits 94-123 are of the form MIDXXXXXX where the first 3-digits (“MID”) form a
country code between “200” and “780”, then digits 1, 2 and 3 (“MID”) form the
country code to be used for data distribution.

4-22

Except as noted above all other country codes outside of the range “200” to “780” are invalid.
4.2.1.1.4
406 MHz FGB Message Validation
If the first protected field of the FGB message (bits 25 - 106) contains any uncorrected BCH errors,
or the FGB beacon fails any condition in Table 4-6, then the MCC shall:
a)
match for the “same beacon ID” based on bits 26 - 85 of the 406 MHz beacon message of
the invalid beacon message with no bits defaulted;
b)
in case of successful match with a previous alert having a valid 406 MHz beacon message:
i.
distribute to Distress authorities using the valid 406 MHz beacon message, and only
include the coded information contained in the beacon ID, and explicitly excluding
encoded position information provided in the valid beacon message; otherwise
ii.
provide the “same beacon ID” per item (a) above in alert messages to Distress
authorities and exclude all other information in the invalid beacon message;
c)
perform no other processing based on any portion of the 406 MHz beacon message;
d)
distribute the alert based on Doppler/DOA position only; and
e)
not distribute the data if there is no Doppler/DOA position.
If the second protected field (bits 107 - 144) has uncorrected BCH errors, then no processing shall
be based on any portion of this field, except for the Supplementary Data Bits as defined in Table
4-6.
If the second protected field has no uncorrected BCH errors and a component value of the encoded
position (i.e., degrees, minutes or seconds) in the second protected field contains an out of range
value (per document C/S T.001), then the encoded position information in the second protected
field shall not be processed.
4.2.1.1.5
406 MHz SGB Message Validation
If the SGB message contains uncorrectable BCH errors (i.e., per MF \#91 does not contain a value
within the range of zero (0) to six (6)) or the SGB message fails any condition in Table 4-6, then
the MCC shall:
a)
match for the same beacon ID based on the 23 Hex ID per the section 3.1.4;
b)
in case of successful match with a previous alert having a valid 406 MHz beacon message,
distribute to Distress authorities using the valid 406 MHz beacon message (per items (d),
(e), and (f) below);
c)
perform no other processing based on any portion of the 406 MHz beacon message
(including rotating fields);
d)
distribute the alert based on DOA position only;
e)
not distribute the data if there is no DOA position; and

4-23

f)
only provide information in alert messages to Distress authorities based on the “same beacon
ID” per item (a) above.
Rotating fields are considered supplemental data. If the SGB message contains no uncorrectable
BCH errors and does not fail any condition in Table 4-6, then each associated rotating field shall
be validated against specified values in Table 4-7. If any rotating field meets any condition in
Table 4-7, then the MCC shall not use any of the component fields in the associated rotating field.
Table 4-7: Rotating Field Validation for SGB\*
Item to Check
Bits
Fail if:
Rotating Field Id
1 – 4
Bits 1 – 4  0000, 0001, 0010, 0011, 0100 or 1111
G.008 Objective
Requirements Rotating
Field
40 - 48
Bits 1- 4 = 0000, and
(Bits 40 – 41 = 11 or bits 42 – 44 = 110 or bits 45 –
46 = 11 or bits 47 – 48  00)
ELT(DT) In-flight
Emergency Rotating
Field
5 - 48
Bits 1- 4 = 0001, and
(Bits 5 - 21 are non-one and encoded value > 86399,
or
Bits 32 - 35  0001, 0100, or 1000, or
Bits 36 – 37 = 11, or
Bits 40 – 48 are not all-zero)
RLS Rotating Field
38 – 48
Bits 1 – 4 = 0010 and bits 38 – 48 are not all-zero
TWC Rotating Field

Bits 1 – 4 = 0100, and
Bit 15 is not-zero ( 0)
Cancellation Rotating
Field
5 – 48
Bits 1 – 4 = 1111 and
(Bits 5 – 46 are all-one and bits 47-48 = 00 or 11)
Note:
* Bits 1 – 48 within a rotating field, which follow the 154-bit main data field, per document
C/S T.018 section “Digital Message Content”.
4.2.1.1.6
Additional Validation
MCCs may perform additional validation to meet national requirements; however, additional
validation shall not affect the distribution of data to other MCCs.
4.2.1.2 Doppler/DOA Position Footprint Validation
Each MCC shall implement the “Algorithm to Determine if Computed Position is Inside Satellite
Footprint”, as specified in document C/S A.002 to determine if:
a)
the Doppler positions are inside the satellite footprint at the time of detection; and
b)
the DOA position is inside the satellite footprints at the time of detection (either first or last
detect time).
If one of the LEOSAR Doppler positions or the DOA position is conclusively outside the footprint
then this failure shall be flagged in alert messages sent by the MCC, as specified in document
C/S A.002.

4-24

4.2.1.3 Encoded Position Footprint Validation
Each MCC shall implement the “Algorithm to Determine if Computed Position is Inside Satellite
Footprint” as specified in document C/S A.002 to determine if the encoded position is inside the
satellite footprint(s) at the time of detection (MF \#14, MF \#14a, or MF \#14b per document
C/S A.002). If the encoded position is conclusively outside the footprint, then no processing shall
be based on the encoded position.
4.2.1.4 Uncorroborated MEOSAR Alerts\*
If a MEOSAR alert is derived from only a single beacon burst (i.e., the associated detect times per
Message Fields \#14a and \#14b in document C/S A.002 are within 2.5 seconds) and from a single
satellite (per Message Field \#83) and no previous alert was generated for the alert site (beacon
activation) that contains data from a different beacon burst, a different satellite or a different
MEOLUT (provided that at least one of the two MEOLUTs, per Message Field \#11, does not
receive antenna data from any other MEOLUT), then the MEOSAR alert is deemed
uncorroborated.
Unless the beacon is an ELT(DT), the MCC shall not distribute an uncorroborated MEOSAR alert
(and shall not distribute an NOCR message):
a)
for an FGB to LEOSAR/GEOSAR only capable MCCs; or
b)
for an SGB to an MCC that is not SGB-capable.
The MCC shall not distribute an uncorroborated MEOSAR alert (and shall not distribute an NOCR
message) to RCCs/SPOCs unless†:
a)
the beacon is an ELT(DT) with a refined encoded position; or
b)
the reporting MEOLUT meets the requirement for processing anomalies (per section
“Processing Anomalies Rate” of document C/S T.019‡); or
c)
it is determined that the beacon ID associated with the MEOSAR alert is registered.
Uncorroborated MEOSAR alerts shall be included in an alert site regardless of whether they are
distributed, so that they are used in subsequent processing for the beacon activation.
* The filtering of  uncorroborated MEOSAR alerts is a temporary mitigation measure to address the high number of
these alerts being delivered by MEOLUTs. It is expected that MEOLUT manufacturers will resolve this issue before
the end of the MEOSAR EOC phase.
† On bilateral basis, an MCC and an RCC/SPOC may agree that the MCC does not send uncorroborated alerts
(including NOCR messages) to the RCC/SPOC.
‡ MEOLUT compliance for processing anomalies shall be configurable at the MCC separately for FGBs and SGBs.

4-25

If a new alert site only contains uncorroborated MEOSAR alert data, then:
a)
any destination that is sent an uncorroborated MEOSAR alert, is treated as a “Previous
recipient” in the processing of subsequent alerts per Table 4-10 and Table 4-11;
b)
the status word is otherwise treated as Sw0 in subsequent processing; and
c)
if a new MEOSAR alert (including an alert deemed redundant per section 3.2.3.2) contains
data from a different beacon burst, a different satellite or a different MEOLUT (provided
that at least one of the two MEOLUTs does not receive antenna data from any other
MEOLUT) than the previous uncorroborated MEOSAR alert data, then the new alert is
distributed to all relevant destination (i.e., to any “previous recipient(s)” and without filtering
alerts to SPOCs and LEOSAR/GEOSAR-only-capable MCCs).
If an NOCR is not sent to a destination (i.e., LEOSAR/GEOSAR only capable MCC or a SPOC)
for an uncorroborated MEOSAR alert per the rules above, then an NOCR shall be sent to the
destination when the first located alert (other than a redundant uncorroborated MEOSAR alert) is
subsequently processed.
4.2.2
Position Matching
Position matching is the comparison of the computed distance between two beacon positions and
a set distance criterion. It is used to decide if two positions should be considered operationally as
a unique beacon position or as separate beacon positions. The matching process can include other
technical parameters. For ELT(DT) alert sites in Pre-G-Switch-Activation status, position
matching is limited to comparing the encoded and DOA position in the same alert so that a position
conflict will be identified if the position difference exceeds the relevant distance match criterion
(per item e below).
Matching criteria are necessary to determine if two sets of independent position data should be
regarded as corresponding to the same beacon position. Such matching criteria are used in the
ambiguity resolution process to determine whether two Doppler positions from two independent
beacon events, or an encoded position and a Doppler position, are sufficiently close to determine
which Doppler position is the “true” position and which is the image or incorrect position(s).
Matching criteria are also used to decide if a separate alert message should be transmitted for a
beacon when a new position is at a distance from any previously received position greater than the
distance separation defined by the matching criteria.
The points listed below concerning the matching of positions apply to the matching criteria
distance to be used by MCCs:
a)
the Doppler to Doppler distance match criterion shall be 20 kilometres for position
confirmation and position conflict;
b)
the Doppler to encoded distance match criterion shall be 20 kilometres for position
confirmation and position conflict;
c)
the encoded to encoded distance match criterion shall be three (3) kilometres for position
conflict;

4-26

d)
the DOA to DOA distance match criterion shall be 20 kilometres for position confirmation
and position conflict;
e)
the DOA to encoded distance match criterion shall be 20 kilometres for position
confirmation and position conflict;
f)
the DOA to Doppler distance match criterion shall be 20 kilometres for position confirmation
and position conflict;
g)
each of the above distance match criteria shall be independently configurable;
h)
in the match process, the “best” match shall be used to confirm position when multiple
candidate positions meet the match criterion; however,
i)
if both pairs of Doppler positions meet the match criterion prior to position confirmation for
different satellite passes, this is deemed an Unresolved Doppler Position Match (see Figure
4-9) and:
i.
position shall not be confirmed from either pair of Doppler positions, and
ii.
other pairs of positions shall remain eligible to resolve ambiguity, even if the “best”
distance match was between ineligible Doppler positions; and
j)
the distance between positions shall be computed independent of altitude (which may be
provided for DOA positions and SGB encoded positions).
Figure 4-9: Unresolved Doppler Match Scenario (20-km Circles)
Pass 1
(A1, B1)
Pass 2
(A2, B2)
A1
B1
A2
B2

![Image 1 from page 74](/images/cospas-sarsat/A-series/A001/A001_page_74_img_1.png)

![Image 2 from page 74](/images/cospas-sarsat/A-series/A001/A001_page_74_img_2.png)

![Image 3 from page 74](/images/cospas-sarsat/A-series/A001/A001_page_74_img_3.png)

![Image 4 from page 74](/images/cospas-sarsat/A-series/A001/A001_page_74_img_4.png)

![Image 5 from page 74](/images/cospas-sarsat/A-series/A001/A001_page_74_img_5.png)

4-27

4.2.3
Position Confirmation
Position Confirmation is the determination of the confirmed beacon position (the resolved
position), as described in section 3.2.4. Details on position matching are provided in section 4.2.2.
4.2.4
Procedures to Determine Better Quality LEOSAR Alert Data for Same Beacon
Event Position Conflicts
4.2.4.1 Introduction
A position conflict exists when an alert is received at an MCC, and the position data fails to match
(see section 4.2.2 above) any previously received position data for the same beacon. MCCs shall
use the filtering procedure detailed below for filtering Doppler position conflict alerts for the same
beacon event prior to and after position confirmation. This procedure is not used for ELT(DT)
alert sites in Pre-G-Switch-Activation status.
The purpose of the filtering procedure is to minimise the distribution of alert messages containing
“poor” quality Doppler position data. If a new alert with Doppler position conflict is for the same
beacon event as previously received data, additional checks can be performed to determine if the
new Doppler position data is of better quality than previously received Doppler position data and
should be transmitted or is of poorer quality and can be deemed redundant. If the relative quality
of the Doppler positions cannot be determined, then the new data should be transmitted. The
procedure below ensures that “good” data will not be suppressed while limiting the amount of
erroneous data distributed to Distress authorities.
4.2.4.2 Doppler Position Conflict Procedure
An MCC should identify a reference alert with Doppler position data for each beacon event. By
default, the first alert for each pass becomes the reference until another alert of better quality is
received. If an alert with new Doppler position data for the same beacon event is received which
is determined to be of better quality, and the new Doppler position fails to match any previously
received position data for the same beacon event, the new alert becomes the reference and a
position conflict alert is transmitted.
An MCC determines if a new alert contains Doppler position data of better quality by performing
the following checks in sequence. The appropriate action is then taken as indicated
(see Table 4-12).
Step 1:
If both alerts have a bias standard deviation less than 20 Hz, then proceed to Step 2. If both alerts
have a bias standard deviation equal to or greater than 20 Hz, or if either bias standard deviation
is not available, then quality differentiation cannot be made, and the new alert is transmitted.
If the reference alert has a bias standard deviation equal to or greater than 20 Hz, and the new alert
has a bias standard deviation less than 20 Hz, then the new alert is deemed to be of better quality,
a position conflict alert is transmitted, and the new alert becomes the reference alert. If the reverse
is true, the new alert is deemed to be of poorer quality and the new alert is not transmitted.

4-28

Step 2:
In this step both alerts are assumed to have bias standard deviations less than 20 Hz. If both alerts
have WF values < 2, then go to Step 3. If the new alert contains a  F ≥ 2, and the reference alert
contains a WF < 2 then the new alert is not transmitted. If the WF of the reference alert contains a
value ≥ 2 and the new alert contains a  F < 2, then the new alert is transmitted and becomes the
reference alert. If both alerts have  F values ≥ 2, then quality differentiation cannot be made, and
the new alert is transmitted.
Step 3:
This step applies when both bias standard deviations are < 20 Hz and both Window Factors are
< 2. In this case, the dimensions of the minor axis of the error ellipse for the “A” solution are
compared.
If the error ellipse minor axis (MIN) of the new alert is ≥ 99.9 and the MIN of the reference alert
< 99.9, then the new alert is not transmitted. If the MIN for the new alert is < 99.9 and the MIN
for the reference alert is ≥ 99.9, then the new alert is transmitted and becomes the reference alert.
Finally, if either of the above conditions are not met, then quality differentiation cannot be made,
and the new alert is transmitted.
If for any reason the relative quality cannot be determined in the comparison of the Doppler
positions from alerts for the same beacon event, the new position data should be transmitted.
Table 4-8: Procedures to Determine Better Quality Alert Data
for Same Beacon Event Doppler Position Conflicts
Parameters
Bias Std Dev (Hz)
MF \#13
Window Factor
(0 - 9)
MF \#15
Min. Axis Error
Ellipse (km)
MF \#27
Steps
Reference
Alert
New
Alert
Reference
Alert
New
Alert
Reference
Alert
New
Alert
Action3
Step 1
< 20 Hz
< 20 Hz
Go to Step 2
default 1
default 1
New alert transmitted
 20 Hz
< 20 Hz
New alert transmitted 2
< 20 Hz
 20 Hz
New alert NOT
transmitted
 20 Hz
 20 Hz
New alert transmitted
Step 2
< 20 Hz
< 20 Hz
< 2
< 2
Go to Step 3
< 20 Hz
< 20 Hz
< 2
 2
New alert NOT
transmitted
< 20 Hz
< 20 Hz
 2
< 2
New alert transmitted 2
< 20 Hz
< 20 Hz
 2
 2
New alert transmitted

4-29

Parameters
Bias Std Dev (Hz)
MF \#13
Window Factor
(0 - 9)
MF \#15
Min. Axis Error
Ellipse (km)
MF \#27
Step 3
< 20 Hz
< 20 Hz
< 2
< 2
< 99.9
 99.9
New alert NOT
transmitted
< 20 Hz
< 20 Hz
< 2
< 2
 99.9
< 99.9
New alert transmitted 2
< 20 Hz
< 20 Hz
< 2
< 2
< 99.9
< 99.9
New alert transmitted
< 20 Hz
< 20 Hz
< 2
< 2
 99.9
 99.9
New alert transmitted
Notes:  1
indicates that at least one bias standard deviation is not available.

indicates that the new alert becomes the reference alert.

if the new alert is transmitted, then the Poor-Quality Flag (PQF) is set to 0; otherwise, PQF
is set to 1.
4.2.5
Detailed Procedures for Alert Data Distribution
4.2.5.1 Analysis and General Representation of Alert Data Processing
Alert data received by a Cospas-Sarsat MCC, either from its associated LUTs or from another
MCC, shall be forwarded to an MCC or a Distress authority if it contains ‘new’ information useful
to Distress authorities. The MCC shall not send an alert message received from another MCC to
the other MCC if the new alert message would contain identical alert information and be sent with
the same SIT number\*.
(\*) The “same alert” message is identified by the beacon message (MF \#92 for an SGB, MF \#77
for an FGB detected by a MEOSAR satellite, or MF \#23 for an FGB detected by a LEOSAR or
GEOSAR satellite), the Source ID (MF \#11), the satellite(s) (MF \#6 or MF \#83), the detect time(s)
(MF \#14, or MF \#14a and MF \#14b), the Doppler / DOA position (MF \#25 and MF \#26, if
present), and (prior to position confirmation) image position determination information in MF \#24,
if present.
The alert data distribution process consists of a set of rules commonly used by Cospas-Sarsat
MCCs for deciding whether new input data concerning a particular 406 MHz beacon ID contains
‘new’ information. It is based on a number of parameters defined in the Cospas-Sarsat Glossary
(document C/S S.011) and matching rules (defined in this document), which include:
•
the definitions of ‘beacon events’, ‘position confirmation’ and ‘position conflict’, and
•
the definition of distance criteria for matching Doppler and encoded position data.
However, these basic rules and the variety of position data available in 406 MHz alert messages
create a large number of possible combinations which need to be thoroughly analysed to ensure
the consistency of the alert data distribution process throughout the Cospas-Sarsat MCC network.
The procedures in section 4.2.5 do not apply to ELT(DT) alert sites in Pre-G-Switch-Activation
status, unless stated otherwise. Procedures for ELT(DT)s are provided in section 3.2.3.2.2.

4-30

In order to implement this data distribution process, the ‘position information content’ of each
valid incoming alert message (referred to as ‘Input’ or ‘I’ in this section) must be compared with
the information already transmitted concerning the same beacon ID. Therefore, the history of all
data already transmitted must be preserved. For each beacon ID, that history can be summarised
in a ‘Status word’ (Sw). Input and Status words are both characterised by the type of position
information (received in the input or transmitted in previous messages). Similarly, the ‘action(s)’
resulting from the process (i.e., the message to be transmitted, its format and recipients) can be
summarised in an ‘Action word’ (Aw) and characterised by the type of position information to be
forwarded, taking also into account position data already distributed. The functional relations
between ‘Input’, ‘Status word’ and ‘Action word’ in the process are summarised in Figure 4-10.
For ELT(DT) alert sites in Pre-G-Switch-Activation status, the new Status word is Sw1 even when
position data was previously received and resulted in an Action word > Aw1, because previous
position data is not used to process a new ELT(DT) alert in Pre-G-Switch-Activation status.
Figure 4-10: Alert Data Processing Concept
4.2.5.2 Definition of Input, Status and Action Words
The possible combinations of position data which characterise an input (I), the current status (Sw)
or the resulting action (Aw) of the process concerning a given beacon ID are identified by the
subscript index, described in Table 4-9. No other combinations of the type of position data are
allowed and the possible position information contents of I, Sw and Aw are summarised in the last
column. Table 4-9 only describes the definition of ‘Input’, ‘Status word’ and ‘Action word’; the
functional relations between ‘Input’, ‘Status word’ and ‘Action word’ are described in Figure 4-
10.
In
Input
Data
Awq
Output
Data
Swp
Swr
In
= Input
Swp
= current Status word
Awq  = Action word
Swr
= new Status word (where r is p or
q, whichever is the greater,
except for ELT(DT) alert sites
in
Pre-G-Switch-Activation
status for which r=1)
Process

![Image 1 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_1.png)

![Image 2 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_2.png)

![Image 3 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_3.png)

![Image 4 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_4.png)

![Image 5 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_5.png)

![Image 6 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_6.png)

![Image 7 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_7.png)

![Image 8 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_8.png)

![Image 9 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_9.png)

![Image 10 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_10.png)

![Image 11 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_11.png)

![Image 12 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_12.png)

![Image 13 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_13.png)

![Image 14 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_14.png)

![Image 15 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_15.png)

![Image 16 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_16.png)

![Image 17 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_17.png)

![Image 18 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_18.png)

![Image 19 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_19.png)

![Image 20 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_20.png)

![Image 21 from page 78](/images/cospas-sarsat/A-series/A001/A001_page_78_img_21.png)

4-31

Table 4-9: Definition of the Input, Status and Action Words for 406 MHz Alerts
Input
Type of position data
Status
word
Action
word
Comments
No
Position
Data
DOA
Doppler
Positions
Encoded
Position
Data
Dop/DOA
Pos.
Confirmed
Dop/DOA
& E
Positions
Matched
Position Information Content


Sw0
Aw0
No message received or sent
I1


Sw1
Aw1
Unlocated alert
I2


Sw2
Aw2
Doppler/DOA positions only
I3


Sw3
Aw3
Encoded position only
I4


Sw4
Aw4
Doppler/ DOA & E positions
all unmatched
I5


Sw5
Aw5
Doppler/DOA pos. only,
position confirmed
I6


Sw6
Aw6
Doppler/DOA pos. (pos.
confirmed) + E pos. unmatched
I7


Sw7
Aw7
Resolved positions
(Doppler/DOA & E matched)
Notes:
-
The Input word (I) is specific to each individual input and independent of the origin of the data (e.g.
another MCC or the LUTs associated with the receiving MCC).
-
The Status word (Sw) summarises all previous inputs and actions in respect of a particular beacon
ID. Sw5, Sw6 and Sw7 each mean that position has been confirmed. However, the distinction between
the various position information contents after position confirmation is relevant for the Input and
Action words.
-
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 (Figure 4-10). The selected Action word is also used to define
the message format to be sent and, before position confirmation, characterises the new status
associated with that beacon ID after completion of the selected Action (i.e., Awi -› Swi).
-
For ELT(DT) alert sites in Pre-G-Switch-Activation status, the Action Word is Aw2 if only DOA
position is present, Aw2 if positions in the new alert (i.e., encoded and DOA position) match each
other, Aw3 if only encoded position is present, and Aw4 if positions in the new alert do not match
each other.
-
For uncorroborated MEOSAR alerts, the Status  ord is set to “Sw0”, as specified in the section
entitled “Uncorroborated MEOSAR Alerts”.
4.2.5.3 Process Matrix for Alerts
The process is summarised in Table 4-10 and Table 4-11 for input LEOSAR/GEOSAR alerts and
input MEOSAR alerts, respectively. These tables define, for each Input / Status combination the

4-32

possible output (Action words), the corresponding SIT message numbers (to be used if the new
data in the Input has to be forwarded to another MCC, outside the processing MCC service area)
and the appropriate recipient(s) of this information, as determined by the geographic sorting of
position data. A single Action Word applies to a specific beacon activation regardless of whether
the data source is the LEOSAR, GEOSAR or MEOSAR system.
Tables 4-10 and 4-11 provide SIT message numbers for alerts in their primary use as alert
messages. Alerts shall also be processed (i.e., sent and received) with SIT message numbers
specific to NOCRs and RLS-capable beacons (as specified in document C/S A.002 table “Subject
Indicator Types for Alert Messages”), in accordance with sections 4.2.7 and 4.2.10, respectively.
4.2.5.3.1
Processing Before Position Confirmation (Sw0, Sw1, Sw2, Sw3, Sw4 Status)
The process is quite simple when no data was previously received for the beacon ID in a new Input
(Status Sw0), or when the previously received alert(s) for that ID did not include any position
information (Status Sw1).
However, as shown in Table 4-10 and Table 4-11, a number of Input / Status combinations may
result in several possible Actions. This occurs when a number of alert messages have been received
prior to the new input, but the available position data did not satisfy the matching criteria for
position confirmation. The new position data in the input message must then be compared with all
positions previously received for the same beacon ID, and these matching tests can lead to different
Actions. The position information content of each possible Action is used to select the appropriate
Action word as illustrated in the special algorithm described in section 4.2.5.4 (Table 4-12, Table
4-13, Table 4-14 and Table 4-15).
4.2.5.3.2
Processing After Position Confirmation (Sw5, Sw6, Sw7 Status)
After position confirmation, the distribution of input alert data is normally continued, and a
different processing logic must be implemented since the initial objective of increasing the position
information content to obtain a confirmed position has already been achieved. To reflect this
different approach, the new ‘Actions’ are identified in the matrices as Cti (see Table 4-10, Table
4-11 and Table 4-15).
Except for additional encoded position, all input position data is compared to the last resolved
position transmitted by the MCC, in accordance with the usual processing criteria. If the process
results in an Action different from Ct0 (redundant data not to be distributed), the input position
data is sent to the destination(s) for which continued transmission is enabled.
Notes:
-
The suffix of Inputs (I words), Actions (Ct) and Status (Sw) remain consistent with the definitions
of Figure 4-10, although there are no practical differences between the three Status words (Sw5, Sw6,
and Sw7) in terms of processing after position confirmation in the proposed procedure.
-
Table 4-10 and Table 4-11 indicates several possible outcomes for all Inputs but one after position
confirmation. However, only one comparison is performed between the new position data in the Input
and the known resolved position, except for additional encoded position. Therefore, the outcome is
always unambiguous and no ‘priority rule’ is required.

4-33

4-34

Table 4-10: Processing Matrix, Message Formats and Distribution of New 406 MHz LEOSAR/GEOSAR Alerts
I1
I2
I3
I4
I5
I6
I7
(no position data)
(A / B Doppler
positions)
(Encoded only)
(A / B / E unmatched) (Confirmed Doppler)
(Conf. Doppler + E
unmatched)
(Confirmed Doppler
and E)
Aw
SIT
Dest
Aw
SIT
Dest
Aw
SIT
Dest
Aw
SIT
Dest
Aw
SIT
Dest
Aw
SIT
Dest
Aw
SIT
Dest
Sw0
Aw1  n22
C
Aw2

AB
Aw3
n22
E
Aw4

ABE
Aw5

R
Aw6

R
Aw7

R
Sw1
Aw0
Aw1
-
n22
-
C
Aw2

ABP
Aw3
n22
EP
Aw4

ABEP Aw5

RP
Aw6

RP
Aw7

RP
Sw2
Aw0
-
-
Aw5
Aw0
Aw2
Aw2


RIP
-
ABP
ABP
Aw7
Aw4
n24
n23
RIP
EP
Aw7
Aw6
Aw4


RIP
RIP
ABEP
Aw5

RIP
Aw6

RIP
Aw7

RIP
Sw3
Aw0
-
-
Aw7
Aw4


RIP
ABP
Aw0
Aw3
-
n23
-
EP
Aw7
Aw4


RIP
ABEP
Aw7
Aw6


RIP
RIP
Aw7
Aw6


RIP
RIP
Aw7

RIP
Sw4
Aw0
-
-
Aw7
Aw6
Aw0
Aw4
Aw4


RIP
RIP
-
ABP
ABP
Aw7
Aw0
Aw4
n24
-
n23
RIP
-
EP
Aw7
Aw6
Aw0
Aw4
Aw4


RIP
RIP
-
ABEP
ABEP
Aw7
Aw6


RIP
RIP
Aw7
Aw6


RIP
RIP
Aw7

RIP
Sw5
Sw6
Sw7
Ct0
-
-
Ct0
Ct2
Ct5


RD
RD
Ct0
Ct3
Ct7
-
n23
n24
-
RD
RD
Ct0
Ct4
Ct7


RD
RD
Ct0
Ct5

RD
Ct0
Ct6

RD
Ct0
Ct7

RD
Notes:  For Ship Security alerts, the destination is “C” for all transmitted messages. “n” is “1” for FGB (e.g., SIT 122), “3” for SGB (e.g., SIT 322).
An SGB example is provided in section 4.2.12. See the section of A.001 titled “Process Matrix for Alerts”.
Ii
= Input
A
= A Doppler position
R
= Confirmed position
Dest = Destination of SIT message
Swi
= Status word
B
= B Doppler position
I
= Incorrect previous position(s)
SIT
=  Subject Indicator Type /
Awi
= Action word
E
= Encoded position
C
= Country code destination
(standard message format)
Cti
= Continue transmission
O
= DOA position
RD = Post Confirmation destination
P
= Previous recipient(s)

4-35

Table 4-11: Processing Matrix, Message Formats and Distribution of New 406 MHz MEOSAR Alerts
I1
I2
I3
I4
I5
I6
I7
(no position data)
(DOA position)
(Encoded only)
(DOA / E unmatched)
(Confirmed DOA)
(Conf. DOA + E
unmatched)
(Confirmed DOA
and E)
Aw
SIT
Dest
Aw
SIT
Dest
Aw
SIT
Dest
Aw
SIT
Dest
Aw
SIT
Dest
Aw
SIT
Dest
Aw
SIT
Dest
Sw0
Aw1  n42
C
Aw2
n45
O
Aw3
n42
E
Aw4
n46
OE
Aw5
n47
R
Aw6
n47
R
Aw7
n47
R
Sw1
Aw0
Aw1
-
n42
-
C
Aw2
n45
OP
Aw3
n42
EP
Aw4
n46
OEP
Aw5
n47
RP
Aw6
n47
RP
Aw7
n47
RP
Sw2
Aw0
-
-
Aw5
Aw0
Aw2
Aw2
n47
-
n46
n45
RIP
-
OP
OP
Aw7
Aw4
n44
n43
RIP
EP
Aw7
Aw6
Aw4
n47
n47
n46
RIP
RIP
OEP
Aw5
n47
RIP
Aw6
n47
RIP
Aw7
n47
RIP
Sw3
Aw0
-
-
Aw7
Aw4
n47
n46
RIP
OP
Aw0
Aw3
-
n43
-
EP
Aw7
Aw4
n47
n46
RIP
OEP
Aw7
Aw6
n47
n47
RIP
RIP
Aw7
Aw6
n47
n47
RIP
RIP
Aw7
n47
RIP
Sw4
Aw0
-
-
Aw7
Aw6
Aw0
Aw4
Aw4
n47
n47
-
n46
n45
RIP
RIP
-
OP
OP
Aw7
Aw0
Aw4
n44
-
n43
RIP
-
EP
Aw7
Aw6
Aw0
Aw4
Aw4
n47
n47
-
n46
n45
RIP
RIP
-
OEP
OEP
Aw7
Aw6
n47
n47
RIP
RIP
Aw7
Aw6
n47
n47
RIP
RIP
Aw7
n47
RIP
Sw5
Sw6
Sw7
Ct0
-
-
Ct0
Ct2
Ct5
-
n46
n47
-
RD
RD
Ct0
Ct3
Ct7
-
n43
n44
-
RD
RD
Ct0
Ct4
Ct7
-
n46
n47
-
RD
RD
Ct0
Ct5
-
n47
-
RD
Ct0
Ct6
-
n47
-
RD
Ct0
Ct7
-
n47
-
RD
Note:
(See Table 4-10)

4-36

4.2.5.4 Special Processing Procedures
4.2.5.4.1
Tests and Flag Setting for Special Processing Procedures
Multiple flags may be positioned to determine the output of an In / Swp combination which requires
special procedures:
DEM = Doppler / DOA to Encoded Positions Matching flag: set to “1” if a D (Doppler or DOA)
position and an Encoded position match the distance separation criterion (and other criteria as may
be required) and set to “0” otherwise. However, in some Input / Status combinations this flag has
no relevance. In such cases the DEM flag is set to its default value “0”. The DEM test is not
applicable after position confirmation.
In the DEM test, the E position of the Input is compared to all received Doppler and DOA
positions, if the position is not confirmed. A correct match of one Doppler or DOA position with
the E position is sufficient to achieve position confirmation. After position confirmation, the E
position is compared to previously received non-redundant E positions if there is previous encoded
position, or to the confirmed position if there is no previous encoded position.
In addition, the A / B Doppler positions or DOA position of the Input are compared with any E
position received at the MCC, if the position is not confirmed. A correct match of any E position
with one Doppler or DOA position is sufficient to achieve position confirmation. After position
confirmation, the confirmed position is compared to the input Doppler positions or DOA position.
If neither of the input Doppler positions matches the confirmed position, then the input Doppler
positions are compared to previous Doppler positions for the SBE to determine redundancy.
SBE = the ‘Same Beacon Event’ flag is to be set for each matching test as follows:
SBE set to “1” if, for the same Beacon ID, previous A / B Doppler positions to be compared with
Input are from same satellite and same TCA +/- 20 minutes.
Otherwise, SBE set to “0”.
The SBE flag is used only in relation with the Doppler to Doppler position matching tests. It has
no relevance for Doppler to DOA, DOA to DOA, DEM or EEM tests and is set to the default value
“0” in such cases.
DBE = the ‘Dependent Beacon Event’ flag is to be set for each matching test as follows:
If, for the same Beacon ID, the new alert contains DOA position and at least one previous alert
contains DOA position, and:
a)
prior to position confirmation:
i.
the unique set of satellites used to compute the new DOA position is not contained
in (or does not contain) the unique set of satellites used to compute a previously
received DOA position and any portion of the time period associated with the new
DOA position (i.e., the time from the first to last burst used to compute the new

4-37

DOA position) is not within two (2) seconds of some portion of the time period
associated with the same previously received DOA position; or
ii.
the unique set of satellites used to compute the new DOA position is contained in
(or contains) the unique set of satellites used to compute a previously received DOA
position and the time of the latest beacon burst used to compute the new DOA
position is not within 30 minutes of the time of the latest beacon burst used to
compute the same previously received DOA position;
then DBE = 0;
otherwise DBE = 1; or
b)
after position confirmation:
i.
the new DOA position matches the confirmed position, and the time of the latest
beacon burst used to compute the new DOA position is within 15 minutes of the
time of the latest beacon burst used to compute a previously sent DOA position that
matched the confirmed position; or
ii.
the new DOA position does not match the confirmed position, and the time of the
latest beacon burst used to compute the new DOA position is within 10 minutes of
the time of the latest beacon burst used to compute a previously sent DOA position
that did not match the confirmed position;
then DBE = 1.
Otherwise (i.e., if DBE is not set per the specifications above) DBE = 0, including DOA to
Doppler, Doppler to Doppler, DEM and EEM position matching tests.
DDM = LUT computed (i.e., Doppler/DOA) position Matching flag: set to “1” if two Doppler
positions, a Doppler position and a DOA position, or two DOA positions match the distance
separation criterion (and other criteria as may be required) and set to “0” otherwise. For an
Unresolved Doppler Position Match (as specified in section 4.2.2) set to “0”. However, in some
Input/ Status combinations this flag has no relevance, for example, if the current status is Sw3
(previous alert data received at the MCC contain only encoded position data). In such cases the
DDM flag is set to default value “0”.
After position confirmation, input Doppler or DOA position is first compared for redundancy test
only with the confirmed position previously processed by the MCC. In addition, if neither new
Doppler position matches the confirmed position, then the new Doppler position data is compared
to previous Doppler position data for the Same Beacon Event. In this context, the DDM test is
reinterpreted as a DRM test (Doppler or DOA to Confirmed Position Matching).
EEM = Encoded position / Encoded position Matching flag: set to “1” if two encoded positions
match the distance separation criterion (and other criteria as may be required) and set to “0”
otherwise. However, the EEM test is relevant only when the Input contains encoded position, a
previous encoded position is available, and (prior to position confirmation) position data in the
Input is not sufficient to achieve position confirmation. In all other situations, the EEM flag should
be set to its default value “0”.

4-38

After position confirmation, the E position is compared to previously received non-redundant E
positions if there is previous encoded position, or to the confirmed position if there is no previous
encoded position.
PQF = Poor Quality Flag: The Poor Quality Flag is used in conjunction with the DDM test only,
when a position conflict exists between Doppler positions for the same beacon event (SBE = 1 and
DDM = 0). In such cases, parameters characterising the quality of the position data are tested to
determine whether the new data provide a better-quality position.
PQF is set to “1” if the new position data is of inferior quality than the data previously processed
by the MCC for the same beacon event. The new data should then be considered as redundant.
PQF is set to “0”:
i.
if the new position data is of better quality than the data previously processed for
the same beacon event; or
ii.
if the relative quality of the new versus the old position data cannot be determined
for the same beacon event; or
iii.
if SBE = 0.
PQF is set to “0” for Doppler to DOA position matches.
For DOA to DOA matches, PQF is set to “1”:
i.
if DDM = 0 and position has been confirmed; or
ii.
if DDM = 0, position has not been confirmed, and at least five (5) position conflict
alerts have been sent that contain DOA position;
otherwise PQF is set to “0” for DOA-to-DOA matches.
SRF = Send Redundant Flag: SRF is used to determine if an alert that is otherwise redundant
should be transmitted. SRF is set to “1”:
a) prior to position confirmation, if the time of the latest beacon burst used to compute the
new DOA position is more than five (5) minutes after the time of the latest beacon burst
used to compute all previously sent DOA positions; or
b) has better quality DOA position, per the procedure “Distribution of Alerts with Better
Quality DOA Position” in section 3.2.3.2.3; or
c) new or updated information is provided in a Rotating Data Field other than a TWC rotating
field, as specified in section 3.2.3.2; or
d) prior to position confirmation, if the new Doppler alert provides Image Position
Determination information not previously processed for the same beacon event; or
e) prior to position confirmation, if the new Doppler position data is of better quality than the
data previously processed for the same beacon event; or
f) new or updated information is provided in a TWC rotating field for Initial
Questions/Answers, as specified in section 4.2.11.

4-39

Otherwise SRF is set to “0”.
4.2.5.4.2
Selection of the Relevant Action in Input / Status Combinations with Multiple
Outputs
When the I / Sw combination leads to several possible actions, it is essential to clarify which Action
in the sequence supersedes others and should be completed. The logic to be followed in this
selection is always that:
a)
Actions enhancing the ‘position information content’ of the alert to be forwarded by the
MCC should have overall precedence (Aw7 > Aw6 > Aw5 > etc.) provided the ‘position
information content’ (or suffix) of the Action word is superior to the suffix of the current
Status word; and
b)
Action Aw0 (which means that the same data as in the Input has already been processed)
has precedence over an Action which has same ‘position information content’ as the
current Status (in Sw4 status, Aw0 > Aw4), except when SRF = 1. This rule reflects the
fact that the Input is redundant, i.e., the Input matches all the characteristics of at least
one set of data previously received, and all other matching tests have failed to enhance
the ‘position information content’ of the possible output.
4.2.5.4.3
Definition of Special Processing Matrices
Special processing matrices are defined for each Status of the process to clarify the implementation
of the test sequence to be performed for each possible input data. The Input / Status combinations
which have a unique output Action (see Table 4-10 and Table 4-11) are not repeated in the special
processing matrices shown in the following sections.
Notes:
Shaded cells in the ‘Input’ columns correspond to flag combinations which are not applicable for
the particular Input / Status combination.
The default value for all flags is “0”. If a test is irrelevant in a particular context (e.g. in the Sw2
status, DEM = 1 and DDM = 1 means the PQF test is irrelevant) then the corresponding flag is set
to “0” and the cell in the matrix is shaded. The flag column is entirely shaded if the corresponding
test is inapplicable for all inputs in the Sw context (e.g. the EEM column in the Sw2 status).
An “X” indicated in the flag column means that both flag values are possible, but the actual flag
value does not affect the output Action (therefore the test can be ignored in this context).
4.2.5.4.3.1 Sw2 Special Processing Matrix
Doppler and/or DOA positions for the same beacon ID have already been processed by the MCC
which receives the new input Ij.
Since no encoded position has previously been received, the EEM test is irrelevant (see shaded
column). Similarly, the PQF test is irrelevant when a DEM test or a DDM test show a successful
match (DEM = 1 and / or DDM =1).

4-40

Table 4-12: Special Processing for Sw2 Status
DEM
SBE/
DBE1
DDM
PQF2
EEM
SRF
I2
[A / B]
or [O]
I3
[E]
I4
[A / B /E)
or [O / E]

X


Aw7

X


Aw7
Aw7


Aw0
Aw4


Aw2
Aw4


Aw0
Aw4


Aw2
Aw4


Aw2
Aw4
Aw4


Aw5
Aw6


Aw2
Aw4
Aw4
Aw priority if multiple matching tests are required
Aw5
> Aw0
> Aw2
Aw7
> Aw4
Aw7
> Aw6
> Aw4
Notes:

DBE is used for MEOSAR input. SBE is used for LEOSAR input.

PQF is always 0 on DOA to Doppler matches.
4.2.5.4.3.2 Sw3 Special Processing Matrix
An ‘E’ (encoded) position for the same beacon ID has already been processed by the MCC which
receives the new input Ij, but no Doppler or DOA position data were received.
Therefore, the Doppler / Doppler, Doppler / DOA and DOA / DOA matching tests, and the
associated SBE, DDM, SRF and PQF tests, are irrelevant in this Status (columns SBE, DDM and
PQF are shaded).
Table 4-13: Special Processing for Sw3 Status
DEM
SBE/
DBE1
DDM
PQF
EEM
I2
[A / B]
or [O]
I3
[E]
I4
[A / B / E]
or [O / E]
I5
[A / B]
or [O]
I6
[A / B+(E)]
or [O / E]


Aw7
Aw7


Aw7
Aw7
Aw7
Aw7


Aw0
Aw4
Aw6


Aw4
Aw3
Aw4
Aw6
Aw6
Aw priority if multiple matching tests are required
Aw7
Aw0
Aw7
Aw7
Aw7
> Aw4
> Aw3
> Aw4
> Aw6
> Aw6
Note:  1 DBE is used for MEOSAR input. SBE is used for LEOSAR input.

4-41

4.2.5.4.3.3 Sw4 Special Processing Matrix
D (Doppler or DOA) positions data and encoded position data for the same beacon ID have already
been processed by the MCC which receives the new input, but no position matching tests have
confirmed position.
Table 4-14: Special Processing for Sw4 Status
DEM
SBE/
DBE1
DDM
PQF
EEM
SRF
I2
[A/B]
or [O]
I3
[E]
I4
[A/B/E]
or [O/E]
I5
[A/B]
or [O]
I6
[A/B+(E)]
or [O/E]

X


Aw7
Aw7
Aw7
Aw7

X


Aw7
Aw7
Aw7
Aw7
Aw7


Aw4
Aw6


Aw0
Aw6


Aw2
Aw4
Aw6
Aw6


Aw0
Aw4
Aw6
Aw6


Aw4
Aw6


Aw0
Aw6


Aw2
Aw4
Aw6
Aw6


Aw0
Aw4
Aw6
Aw6

X


Aw0
Aw4
Aw6

X


Aw4
Aw4
Aw4
Aw6
Aw6


Aw6
Aw6


Aw6
Aw6
Aw6
Aw6
Aw priority if multiple matching tests are required
Aw7
> Aw6
> Aw0
> Aw4
> Aw2
Aw7
> Aw0
> Aw4
Aw7
> Aw6
> Aw0
> Aw4
Aw7
> Aw6
Aw7
> Aw6
Note:
1  DBE is used for MEOSAR input. SBE is used for LEOSAR input.
4.2.5.4.3.4 Special Filtering Matrix After Position Confirmation
It is assumed that continued transmission is enabled, otherwise no action should be taken when
receiving new alerts for the particular beacon ID under consideration.
The Reference position (i.e., the confirmed position) shall be updated when MCC processing has
reliably determined that it is no longer viable, i.e., if, based on time of detection, non SBEs and
non DBEs as defined for prior to position confirmation in section 4.2.5.4.1 entitled “Tests and Flag
Setting for Special Processing Procedures”:
a)
there is a minimum number of conflicts (10) over a maximum period of time (60 minutes);
and
b)
the majority (≥ 70%) of these conflicts are matching the newly updated Reference position
per the matching criteria as detailed in section 4.2.2 entitled “Position Matching”.
Note: the above values in parentheses ( ) shall be configurable numbers.

4-42

The filtering procedure after position confirmation is as follows:
a)
the Doppler position data received in the new input is compared first to the resolved position
(R) used for reference (i.e., the DRM test replaces the DDM test);
b)
if neither new Doppler position matches the resolved position, then the new Doppler position
data is compared to previous Doppler position data for the Same Beacon Event;
c)
the DOA position data received in the new input is compared only to the resolved position
(R) used for reference (i.e. the DRM test replaces the DDM test);the encoded position data
received in the new input is compared to previous encoded position, unless there is no
previous encoded position, in which case it is compared to the resolved position (R) used for
reference;
d)
all new beacon events are transmitted, based on the setting of the Same/Dependent Beacon
Event flag; and
e)
position data for Same/Dependent beacon events is forwarded if any one of the possible tests
fails.
Table 4-15: Special Processing for Sw5, Sw6 and Sw7 Status
SBE/DBE1
DRM
PQF
EEM\*
SRF
I2
[A/B]
or [O]
I3
[E]
I4
[A/B/E]
or [O/E]
I5
[A/B]
or [O]
I6
[A/B+(E)]
or [O/E]
I7
[Conf.
D+E]


Ct7
Ct6
Ct7


Ct0
Ct0
Ct0


Ct7
Ct5
Ct6
Ct7


Ct0
Ct4
Ct0
Ct6
Ct7


Ct0
Ct0
Ct0


Ct2
Ct4
Ct5
Ct6
Ct7


Ct0
Ct4
Ct0
Ct6
Ct7


Ct0
Ct4
Ct6
Ct7


Ct2
Ct3
Ct4
Ct5
Ct6
Ct7


Ct7
Ct6
Ct7


Ct5
Ct4
Ct5
Ct6
Ct7


Ct7
Ct4
Ct6
Ct7


Ct2
Ct3
Ct4
Ct5
Ct6
Ct7
Notes: 1
DBE is used for MEOSAR input. SBE is used for LEOSAR input.
\*
The encoded position data received in the new input is compared to the resolved position (R)
used for reference if there is no previous encoded position.
4.2.6
Distribution of Beacon Registration Information
The identification data in the beacon message includes a code which identifies the country where
the beacon is registered.  hen an MCC acquires distress alert or NOCR data (based on the alert’s
country code), the MCC can determine if it has access to the registry data. If so, the beacon
registration could be transmitted to the MCC in whose service area, the Doppler, DOA or encoded
position is located, using the SIT 925 or SIT 926 message format. Registration data shall be routed

4-43

in accordance with Table 4-1. The registration data would only be sent upon the first reception of
an alert or NOCR message.
The beacon ID contained in the SIT 925 or SIT 926 message can be used by the receiving MCC
to correlate it to a previously received alert message and forward the registry data to the appropriate
Distress authority.
An MCC is not required to automatically transmit registration data from its registry to other MCCs.
However, the reception of this data is required by all MCCs.
An MCC receiving an NOCR alert may respond with registration data without being specifically
requested.
4.2.7
NOCR Procedures
4.2.7.1 Procedure
An MCC shall initiate an NOCR message when a 406 MHz alert for a beacon ID is first located,
except when specified otherwise. The location can be provided by Doppler location processing,
DOA location processing or the encoded position contained in beacons coded using a location
protocol. The processing of NOCRs for alert sites with an uncorroborated alert is specified in the
section entitled “ ncorroborated MEOSAR Alerts”.
An MCC that initiates an NOCR message shall transmit the message to the associated MCC (i.e.,
the destination MCC) based on the distribution matrix provided in Table 4-1. The appropriate
associated MCC for NOCR message distribution is determined by the country code contained in
the beacon ID of the message, so that the NOCR is distributed to the country that maintains the
beacon registry for that country code, as provided on the Cospas-Sarsat website "Contact List" for
"406 MHz Beacon Registers (available 24/7 for SAR Services)".
In addition to distributing the NOCR message to the appropriate SPOC or MCC, the associated
MCC shall process the NOCR message as an alert message, in accordance with Table 4-10 and
Table 4-11.
An NOCR message is not sent for unlocated alerts because, by definition, an NOCR message
includes position information. An MCC is not required to send an NOCR message to a destination
(SPOC or MCC) if the sending MCC transmits the alert to that destination as an alert message,
unless the sending MCC and the destination are nodal MCCs.
The receiving MCC shall filter redundant NOCRs for the same beacon ID.
4.2.7.2 NOCR Example (FGB)
Scenario
•
Country code in Beacon ID: Sweden (265)
•
“A” Position Service Area: A MCC (Australian MCC)
•
“B” Position Service Area: CHMCC (Chilean MCC)

4-44

•
Doppler alerts received by the AUMCC and the CHMCC from an associated LEOLUT
with the “A” location in the A MCC SRR and the “B” location in the CHMCC SRR.
The USMCC received the alert message from the CHMCC prior to receiving the alert
message from the AUMCC.
USMCC
“A”
AUMCC
“B”
CHMCC
NMCC
(associated MCC)
FMCC
SPOC/RCC
SPOC/RCC
Sweden
(SPOC)
Figure 4-11: NOCR Example (FGB)
4.2.8
Distribution of 406 MHz Ship Security Alerts
The identification data in the beacon message includes a protocol code which can identify the 406
MHz transmission as a ship security alert. In addition, the beacon message also contains a country
code which can be associated with the “flag state” of the vessel.  hen an MCC receives a ship
security alert, the alert shall be processed according to the same procedures that apply for distress
alerts except that the resulting ship security alert message will be forwarded based only on the
country code included in the beacon message.
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.

4-45

4.2.8.1 Procedure
An MCC shall process ship security alerts (FGB message bits 37-40 = 1100) according to the logic
provided in Table 4-10 and Table 4-11. Routing of ship security alerts shall be based on the country
code contained in the beacon message, that is, the message will be transmitted to the MCC
associated with the country code, and not transmitted to other MCCs, RCCs, or SPOCs based on
the Doppler locations, DOA position or encoded position contained in the beacon message.
Message routing for ship security alerts shall follow the data distribution matrix as provided at
Table 4-1. Ship security alerts shall be exchanged between MCCs using the formats and data
content for alert messages as contained in document C/S A.002.
When a ship security alert is received by the Associated MCC, MCC shall notify the relevant
competent security authority as provided by IMO or another appropriate point of contact as
previously arranged.
The Associated MCC shall continue to provide information to the competent authority after
position confirmation, as described in section 3.2.5.
4.2.8.2 Ship Security Alert Examples
Scenario 1 (FGB)
•
Country code in Beacon ID: Sweden (265),
•
Initial Alert with Doppler Location,
•
“A” Position Service Area: A MCC (Australian MCC),
•
“B” Position Service Area: CHMCC (Chilean MCC),
•
Receiving MCC: CHMCC.

4-46

“A”
AUMCC
USMCC
NMCC (Associated
MCC)
FMCC
“B”
CHMCC
Sweden
(Competent
Authority)
RCC
SIT 125
SIT 125
SIT 125
SIT 185
Figure 4-12: Ship Security Alert Examples (Scenario 1)
Scenario 2 (SGB)
•
Country code in Beacon ID: Panama
•
Initial Alert with DOA Position
•
DOA Position Service Area: SPMCC (Spanish MCC)
•
Receiving MCC: SPMCC

4-47

USMCC
(Associated MCC)
SPMCC
RCC
Panama
(Competent
Authority)
SIT 345
SIT 185
Figure 4-13: Ship Security Alert Examples (Scenario 2)
4.2.9
Processing and Distribution of 406 MHz Interference Data
4.2.9.1 406 MHz Interference Data Processing
When processing 406 MHz interference data, the matching of interferer solutions is based strictly
on location, with a 100-km criterion. In addition, the thresholds for closing interferer sites (i.e., for
resetting the interferer activation status to zero) 72 hours without new data or 20 missed LEO
satellite passes, takes into account the fact that interferers often do not transmit continually.
4.2.9.2 406 MHz Interference Data Distribution
MCCs exchange 406 MHz interference data from LEOLUTs and MEOLUTs in the SIT 121 and
SIT 141 message formats, respectively. MCCs shall automatically distribute 406 MHz interference
data to other MCCs only when the position is confirmed, based on the location of the interferer.
MCCs shall send at least two messages to other MCCs for each interferer site.
Interference data received from MEO satellites shall be processed and distributed independently
from interference data received from LEO satellites.
4.2.10 Return Link Service (RLS) Procedures
4.2.10.1 Procedure
An MCC shall initiate a Return Link Service (RLS) message to the MCC associated with the
Return Link Service Provider (RLSP) as specified in Table 4-16 when the position of a 406 MHz
beacon with Return Link capability is confirmed to be in the MCC’s service area. An RLS message
is only sent for beacons with Return Link capability, based on the Location Protocol encoded in

4-48

beacon message bits 37 – 40 for FGBs and beacon message bit 42 for SGBs. Beacon position is
confirmed, as specified in section 3.2.4. The MCC associated with the RLS provider shall
distribute RLS messages to the designated RLSP, as specified in Table 4-16. If the designated
RLSP is not known (i.e., PDF-2 of the FGB beacon message is not usable, an SGB message with
a usable RLS rotating field is not available, or the associated MCC is not specified in Table 4-16
for an RLS Provider ID), then a position confirmation alert shall be sent to each MCC associated
with a designated RLS provider.
Table 4-16: Associated MCCs for Return Link Service Providers
Satellite
Constellation
RLSP
Associated MCC
SAR/Galileo
FMCC
Glonass\*
CMC
SAR/BDS**
CNMCC
Notes:  *  Glonass is not currently a designated RLS provider but may provide this capability in the
future.
** The space segment for RLS/BDS is available for service. However, the commencement of
service is pending the completion of upgrade and commissioning of associated ground
segment and successful RLS/BDS testing.
RLS messages shall be transmitted to the MCC(s) associated with the RLS provider(s) based on
the distribution matrix provided in Table 4-1. In addition to distributing the RLS message to the
appropriate MCC or the RLSP, MCCs shall also process the RLS message as an alert message, in
accordance with Table 4-10 and Table 4-11.
After position confirmation, if the status of the Acknowledgement Type-1 received by the beacon
(based on FGB message bit 111, or SGB message bit 170 when the RLS rotating field is present)
changes vs. the status in the previous alert sent to the RLSP, then the new alert shall be initiated
by the MCC in whose service area position was confirmed and sent to the MCC(s) associated with
RLS provider(s) previously notified with a position confirmation alert. A new alert shall only be
sent to the MCC(s) associated with RLS provider(s) after position confirmation if:
a)
PDF-2 of the FGB message or the RLS rotating field of the SGB message is usable; and
b)
The time of the latest burst in the new alert is later than the time of the latest burst in the
previous alert sent for the beacon to the associated MCC(s) for the RLS provider(s). If the
time of the latest burst is not known for an alert with Doppler position, then the TCA is used
as the time of the latest burst.
MCCs shall distribute alerts for test coded RLS beacons (including NOCRs, when beacon message
bits 41-42 = 11 for RLS-capable FGBs, or when beacon message bit 43 = 1 for RLS-capable SGBs)
to other MCCs that are capable of processing these alerts automatically (i.e., to an FGB-RLS
capable MCC for an FGB and to an SGB-capable MCC for an SGB), including the MCC(s)
associated with the RLS provider(s), in the same manner that operationally coded RLS-capable

4-49

beacons are distributed. MCCs shall not distribute alerts (including NOCRs) for test coded RLS
beacons to RCCs or SPOCs, or MCCs that are not capable of processing these alerts automatically.
Further information on the Acknowledgement Type-1 Return Link Service is provided in
document C/S R.012 “Cospas-Sarsat 406 MHz MEOSAR Implementation Plan”.
4.2.10.2 RLS Example (FGB)
Scenario
•
Country code in Beacon ID: Australia (503)
•
Confirmed (DOA) Position Service Area: CMCC (Canadian MCC)
•
Beacon coded for the Sar/Galileo Return Link Service
Figure 4-14: RLS Example (FGB)
4.2.11 Two-Way Communication (TWC) Procedures
4.2.11.1 Procedure
An MCC shall initiate a Two-Way Communication (TWC) message to the MCC associated with
the Two-Way Communication Service Provider (TWC-SP) as specified in Table 4-17 when the
USMCC
FMCC
RLS
Provider
DOA
Confirmed
CMCC
SPOC / RCC
SIT 139
SIT 139

![Image 1 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_1.png)

![Image 2 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_2.png)

![Image 3 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_3.png)

![Image 4 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_4.png)

![Image 5 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_5.png)

![Image 6 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_6.png)

![Image 7 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_7.png)

![Image 8 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_8.png)

![Image 9 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_9.png)

![Image 10 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_10.png)

![Image 11 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_11.png)

![Image 12 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_12.png)

![Image 13 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_13.png)

![Image 14 from page 97](/images/cospas-sarsat/A-series/A001/A001_page_97_img_14.png)

4-50

initial position (DOA or Encoded) of a 406 MHz beacon with TWC capability is determined to be
in the MCC’s service area.
A TWC message is only sent for beacons with TWC capability, based on the TWC functionality
encoded within the TWC rotating field(s) and with bit 42 = 1 in beacon message for SGBs.
The MCC associated with the TWC-SP shall distribute TWC messages to the designated TWC-
SP, as specified in Table 4-17. If the designated TWC-SP is not known (i.e., an SGB message with
a usable TWC rotating field is not available, or the associated MCC is not specified in Table 4-17
for a TWC-SP ID), then a located alert shall be sent to each MCC associated with a designated
TWC-SP.
Table 4-17: Associated MCCs for TWC Service Providers
Satellite
Constellation
TWC-SP
Associated
MCC
SAR/Galileo
FMCC
Glonass\*
CMC
SAR/BDS**
CNMCC
Notes:
* Glonass is not currently a designated TWC-SP but may provide this capability in the future.
** The space segment for RLS/BDS is available for service. However, the commencement of service is
pending the completion of upgrades, commissioning of associated Ground Segment equipment, and
successful RLS/BDS testing.
TWC messages, using RLS notification formats (SIT 334, 338 or 339), shall be transmitted to the
MCC(s) associated with the TWC Service Provider(s) based on the distribution matrix provided
in Table 4-1.
In addition to distributing the TWC message to the appropriate MCC or the TWC-SP, MCCs shall
also process the TWC message as an alert message, in accordance with Table 4-10 and Table 4-11.
If available, Initial Questions (as per official dataset provided in [TBD]) and their answers shall
be processed, based on all approved versions of the dataset, and included in alert messages by the
destination MCC and sent to the SPOC/RCC (according to document C/S A.002 Message Field
\#60).
Whenever new content related to the Initial Questions/Answers is provided, an update of the alert
message shall be sent to RCC(s)/SPOC(s).
If the content of the TWC rotating field changes with respect to the content in the previous message
sent to the TWC-SP(s), then the new alert shall be sent to the MCC(s) associated with TWC-SP(s)
previously notified.
A new alert shall only be sent to the MCC(s) associated with TWC-SP if:
a)
the TWC rotating field of the SGB message is usable; and

4-51

b)
the time of the latest burst in the new alert is later than the time of the latest burst in the
previous alert sent for the beacon to the associated MCC(s) for the TWC-SP(s).
An MCC shall distribute alerts for test coded TWC beacons (including NOCRs) to other MCCs
that are capable of processing these alerts automatically (i.e., to an SGB-capable MCC for an
SGB), including the MCC(s) associated with the TWC-SP(s), in the same manner that
operationally coded TWC-capable beacons are distributed.
An MCC shall not distribute alerts (including NOCRs) for test coded TWC beacons to RCCs or
SPOCs, nor to MCCs that are not capable of processing these alerts automatically.
4.2.11.2 TWC Example (SGB)
Scenario
•
Country code in Beacon ID: Greece (237)
•
Initial (DOA) Position Service Area: SPMCC (Spanish MCC)
•
Beacon coded for the SAR/Galileo TWC Service Provider
Figure 4-15: TWC Example (SGB)
GRMCC
FMCC
TWC-SP
DOA
SPMCC
SPOC / RCC
SIT 337
SIT 339
RCC
Interface
SIT 185

![Image 1 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_1.png)

![Image 2 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_2.png)

![Image 3 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_3.png)

![Image 4 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_4.png)

![Image 5 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_5.png)

![Image 6 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_6.png)

![Image 7 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_7.png)

![Image 8 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_8.png)

![Image 9 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_9.png)

![Image 10 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_10.png)

![Image 11 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_11.png)

![Image 12 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_12.png)

![Image 13 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_13.png)

![Image 14 from page 99](/images/cospas-sarsat/A-series/A001/A001_page_99_img_14.png)

4-52

4.2.12 Cancellation Message Procedures
Cancellation messages are transmitted to indicate that the distress condition associated with a
beacon activation has ceased.
An FGB message is a cancellation message if:
a)
all bits that comprise this message exactly match the specified fixed bit pattern of the
Protected Data Field 1 (PDF-1) for a cancellation message;
b)
there are no uncorrected bit errors in PDF-1; and
c)
PDF-1 is valid for an FGB (per Table 4-6);
otherwise, the FGB message is deemed a non-cancellation message.
An FGB cancellation message is deemed complete if:
a)
all bits that comprise this message exactly match the specified fixed bit pattern of the
Protected Data Field 2 (PDF-2) for a cancellation message; and
b)
there are no uncorrected bit errors in PDF-2;
otherwise, the FGB message is deemed incomplete.
An SGB message is a cancellation message if:
a)
all bits that comprise this message exactly match the specified fixed bit pattern for a
cancellation message;
b)
there are no uncorrected bit errors in the beacon message; and
c)
the Main Data Field is valid for an SGB (per Table 4-6);
otherwise, the SGB message is deemed a non-cancellation message.
An SGB cancellation message is deemed complete if the Rotating Data Field is valid for an SGB
(per Table 4-6 and Table 4-7). Otherwise, the SGB cancellation message is deemed incomplete.
A cancellation message is considered to be confirmed if three (3) complete cancellation messages)
are received from different beacon bursts (i.e., with detect times separated by at least 2.5 seconds)
and with associated detect times all within a single 110-second period, and either:
a)
no non-cancellation alert message with a valid PDF-1 (per section 4.2.1.1.3 entitled
“406 MHz Beacon Message Validation”) is received with a burst time between the burst
times of the first and last cancellation message for an FGB; or
b)
no valid non-cancellation alert message with a valid Main Data Field (per section
4.2.1.1.3) is received with a burst time between the burst times of the first and last
cancellation message for an SGB.

4-53

MCCs shall process cancellation messages as follows:
a)
if an unconfirmed, complete cancellation message is received, then the associated alert
message shall be distributed to all current MCC destinations, that are:
i.
SGB-capable, if the beacon is an SGB, or
ii.
FGB ELT(DT)-capable, if the beacon is an FGB;
b)
all cancellation messages received until cancellation is confirmed (including the confirming
cancellation message, incomplete FGB messages, and unconfirmed complete messages)
shall be processed as alerts without regard to their cancellation status;
c)
if a confirming cancellation message is received:
i.
the beacon activation status is deemed “confirmed cancellation”, and
ii.
the associated alert message, formatted in accordance with document C/S A.002,
shall be distributed to:
a.
all current MCC(s),
b.
Distress authority destination(s),
c.
the LADR for ELT(DT)s,
d.
the designated RLSP for RLS-capable beacons,
e.
the designated TWC-SP for TWC-capable beacons;
d)
any cancellation message received while the beacon activation status is “confirmed
cancellation” shall be filtered; and
e)
cancellation messages shall not be transmitted to Distress authority destinations until
cancellation is confirmed.
All non-cancellation alert messages that do not have an associated detect time after the earliest
detect time of the set of three cancellation messages used to confirm the most recent cancellation
(i.e., the beacon activation status is “confirmed cancellation”), shall be filtered.
If any associated detect time of a new non-cancellation alert message is after the earliest detect
time of the set of three cancellation messages used to confirm the most recent cancellation, and
the beacon activation status is “confirmed cancellation”, then the new alert shall be treated as a
new beacon activation (i.e., the beacon activation status word (Sw) is reset to zero, per section
4.2.5) and the beacon activation status is no longer “confirmed cancellation”.
4.2.13 SGB example
Scenario
•
Country code in Beacon ID: Brazil (710)
•
(Matching DOA, Encoded) Position Service Area: CHMCC (Chilean MCC)

4-54

Figure 4-16: SGB Example
4.3
Procedures for the Co-Ordination of Beacon Tests
Section 3.8 of C/S A.001 defines the principles governing the implementation of tests using
beacons coded with operational or test protocols. The following procedures should be implemented
by the MCC responsible for the test for co ordinating the requirements of the test with all affected
MCCs (i.e., designated MCCs, as specified in section 3.8 above). This procedure does not apply
to international exercises approved by the Council, an Experts Working Group, a Task Group or
the Joint Committee.
The co-ordination of operational beacon tests performed under the control of a national
administration shall consist of an advance submission of a text (SIT 915) message as shown in
Figure 4-17 “Beacon Test Co-ordination Message”. The message shall include the 15 or 23
hexadecimal ID (per section 3.1.4) and indicate if the beacon will transmit in self-test mode, since
this information cannot be derived from the hexadecimal ID. The extent of required co-ordination
will depend on beacon protocol (operational or test) and the number of beacons used, as shown in
Table 4-. If a test involves an operationally coded ELT(DT), then the responsible MCC shall co-
ordinate the test with the LADR host.
Co-ordination of tests is not required when a beacon operator activates a beacon in self-test mode
for a single burst but is required for a test that involves a series of self-test mode transmissions
(e.g., a test of LUT or SGB capability), as specified in Table 4-18.
The Beacon ID must conform to the definition given in the Cospas-Sarsat Glossary (document
C/S S.011).
USMCC
CHMCC
DOA/ Encoded
BRMCC
SPOC / RCC
SIT 345
SIT 345

![Image 1 from page 102](/images/cospas-sarsat/A-series/A001/A001_page_102_img_1.png)

![Image 2 from page 102](/images/cospas-sarsat/A-series/A001/A001_page_102_img_2.png)

![Image 3 from page 102](/images/cospas-sarsat/A-series/A001/A001_page_102_img_3.png)

![Image 4 from page 102](/images/cospas-sarsat/A-series/A001/A001_page_102_img_4.png)

4-55

SIT 915 < MESSAGE>
DATE: DD MM YY
FM:
MCC SUPPORTING THE 406 MHz TEST
TO:
AFFECTED (DESIGNATED) MCCs
SUBJ: BEACON TEST
A.
TEST OBJECTIVE:
B.
TEST DESCRIPTION:
C.
LOCATION OF TEST: DD MM.MMM [N/S] DDD MM.MMM [E/W]
D.
DATE, TIME AND DURATION OF TEST:
E.
BEACON IDS AND TRANSMISSION TYPE:
15 OR 23 HEXADECIMAL CHARACTERS TRANSMISSION TYPE IS SELF-TEST,
AS APPLICABLE.
F.
SPECIAL DATA COLLECTION AND PROCESSING REQUIREMENTS:
G.
POINT OF CONTACT
NAME:
LOCATION:
TELEPHONE NO:
AFTN/AMHS NO:
EMAIL ADDRESS:
TELEX NO:
FACSIMILE NO:
Figure 4-17: Beacon Test Co-ordination Message

4-56

Table 4-18: Notification Time Requirement for Submission
of Co-ordination Information Indicated in Figure 4-17
Beacon
Type
Number
of
Messages
Beacon Protocol
Beacons
Used
Required
Operational
Test
FGB,
SGB
1 - 3
Initial Notification
Second Notification
End-of-Test
Notification
As soon as practical
24 hours prior to the
activation of the first
beacon \*
Upon deactivation of
the last beacon as
required
Not required
Not required
Not required
FGB
4 – 6 **
Initial Notification
Second Notification
End-of-Test
Notification
7 days prior to the
date of the test
24 hours prior to the
activation of the first
beacon \*
Upon deactivation of
the last beacon as
required
7 days prior to the
date of the test
24 hours prior to the
activation of the
first beacon \*
Upon deactivation
of the last beacon as
required
SGB
4 – 12 **
Initial Notification
Second Notification
End-of-Test
Notification
7 days prior to the
date of the test
24 hours prior to the
activation of the first
beacon \*
Upon deactivation of
the last beacon as
required
7 days prior to the
date of the test
24 hours prior to the
activation of the
first beacon \*
Upon deactivation
of the last beacon as
required
Notes:  \*
This set of information will be an update, if necessary, of the original set.
**
Tests involving more than six (6) FGBs or 12 SGBs are not authorized.

4-57

4.4
LEOLUT Orbit Vector Update Method
There are three methods for LEOLUT orbit vector updates for each Cospas-Sarsat satellite: use of
the downlink signal, use of orbitography beacon information, and use of orbit vector data supplied
by an MCC. Which method offers the more accurate orbit vector determination for a given satellite
pass depends on the satellite's SAR instrument status and how often orbit vectors are available at
the LUT from the MCC.
If the SAR instrument status of a satellite is such that any of the three update methods can be used,
the preferred update method is through orbitography beacons. Table 4-19 provides guidelines for
each satellite with the update methods listed such that the preferred method is number 1.
Table 4-19: Orbit Vector Update Method
Satellite
Orbit Vector Update Method
Sarsat-7, Sarsat-10, Sarsat-11, Sarsat-12 and
Sarsat-13
1.
Orbitography
2.
MCC Provided Orbit Vectors
3.
Downlink
- END OF SECTION 4 -

5-1

5.
COSPAS-SARSAT SPACE AND GROUND SEGMENT DESCRIPTION
5.1
SID Implementation Status
Document C/S A.002, “Cospas-Sarsat Mission Control Centres Standard Interface Description”,
contains standardised message formats, identified by “Subject Identifier Type” (SIT) codes, which
may be used by MCCs.
The tables shown below indicate which SITs for System information messages and alert and
narrative messages have been implemented by the various MCCs.
They also indicate whether the capability is “receive”, “originate”, “both receive and originate”,
or “not implemented”.
5.1.1
System Information Messages
MCC
SIT Number
Name


AEMCC
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
ALMCC
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
ARMCC
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
ASMCC
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
AUMCC
B
B
-
B
-
B
-
-
-
B
-
-
-
-
B
BRMCC
R
-
R
-
R
-
-
-
R
-
-
-
-
B
CHMCC
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
CMC
B
R
[B]
R
-
R
-
-
-
-
-
-
-
-
B
CMCC
R
R
-
R
-
R
-
-
-
B
R
R
O
R
B
CNMCC
R
[B]
R
-
TBD
-
-
-
-
-
-
-
-
B
CYMCC
R
-
R
-
R
-
-
-
-
-
-
-
-
B
FMCC
B
B
B
B
B
B
R
O
R
-
-
-
-
-
B
GRMCC
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
HKMCC
R
-
R
-
R
-
-
-
-
-
-
-
-
B
IDMCC
R
-
R
-
R
-
-
-
-
-
-
-
-
B
INMCC
R
-
R
-
TBD
-
-
-
-
-
-
-
-
B
ITMCC
R
-
R
-
TBD
-
-
-
-
-
-
-
-
B
JAMCC
R
R
B
R
-
R
-
-
-
-
-
-
-
-
B
KOMCC
R
-
R
-
TBD
-
-
-
-
-
-
-
-
B
MYMCC\*
[R]
-
[R]
-
[R]
-
-
-
-
-
-
-
-
[B]
NIMCC**
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
NMCC
R
-
R
-
TBD
-
-
-
-
-
-
-
-
B
PAMCC
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
PEMCC
R
-
R
-
R
-
-
-
-
-
-
-
-
B
QAMCC
R
-
R
-
R
-
-
-
-
-
-
-
-
B
SAMCC
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
SIMCC
R
-
R
-
R
-
-
-
-
-
-
-
-
R
SPMCC
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
TAMCC
R
-
R
-
TBD
-
-
-
-
-
-
-
-
B
TGMCC\*
[R]
-
[R]
-
[R]
-
-
-
-
-
-
-
-
[B]
THMCC
R
-
R
-
TBD
-
-
-
-
-
-
-
-
B
TRMCC
R
R
-
R
-
R
-
-
-
R
-
-
-
-
B
UKMCC
R
-
R
-
TBD
-
-
-
R
-
-
-
-
B
USMCC
B
O
B
B
O
B
O
R
O
B
O
O
R
O
B
VNMCC
R
R
-
R
-
R
-
-
-
-
-
-
-
-
B
Legend:
O:
originate
R:
receive
**:
Commissioned not operational
B:
both originate and receive
-:
not implemented
TBD:
to be determined
\*:
under development

5-2

5.1.2
Alert and Narrative Messages
SIT messages 121 to 135 contain LEOSAR/GEOSAR data for FGBs. SIT messages 136 to 147 contain MEOSAR data for FGBs. SIT messages
322 to 347 contain alert data for SGBs. See section “Subject Indicator Types for Alert Messages” in document C/S A.002.
MCC Name

122 - 127
132 - 133
134 - 139

142 - 147

322 - 347


AEMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
ALMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
ARMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
ASMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
AUMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
BRMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
CHMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
CMC
B
B
B
-
-
-
B
-
B
B
-
-
-
CMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
CNMCC
B
B
B
-
-
-
B
-
B
R
-
-
-
CYMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
FMCC
-
B
B
B
B
B
B
-
B
B
-
-
-
GRMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
HKMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
IDMCC
B
B
B
-
-
-
O
-
B
B\*
-
-
-
INMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
ITMCC
B
B
B
B
B
B
B
-
B
TBD
-
-
-
JAMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
KOMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
MYMCC\*
[B]
[B]
[B]
-
-
-
[B]
-
[B]
[B]
-
-
-
NIMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
NMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
PAMCC
B
B
B
-
-
-
O
-
B
B
-
-
-
PEMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
QAMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
SAMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
SIMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
SPMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
TAMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
TGMCC\*
[B]
[B]
[B]
[B]
[B]
[B]
THMCC
B
B
B
-
-
-
B
-
B
B
-
-
-
TRMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
UKMCC
B
B
B
B
B
B
B
-
B
B
-
-
-
USMCC
B
B
B
B
B
B
O
B
B
B
-
VNMCC
B
B
B
-
-
-
B
-
B
B
-
Legend:
O:   Originate R:   Receive
B:   Both originate and receive
TBD:   To be determined
-:   Not implemented \*:   Under development

5-3

5.2
Status of Space Segment
The Cospas-Sarsat website provides the current status of Cospas-Sarsat Space Segment payloads.
Each satellite platform provider shall commission new satellite payloads according to the
procedures documented in documents C/S T.004, C/S T.013 and C/S T.017. Additionally, after a
payload is declared operational, and whenever there is a change in the configuration or status of a
satellite payload, the Space Segment Providers shall notify all Ground Segment Operators and the
Secretariat. The message format described in Figure 5-1 shall be used to provide this notification.
Figure 5-2 is a standard message for reporting satellite manoeuvres.
Figure 5-3 shows a standard message for reporting reactivation of the SARP instrument.
Figure 5-4 is a standard message for reporting a spacecraft anomaly.

5-4

/12345 00000/3660/97 123 1234
/605/5030
/TO: ALL MCCS
FROM: <MCC ASSOCIATED WITH SATELLITE OR PAYLOAD PROVIDER>
SUBJECT:   A) INITIAL OPERATIONAL CAPABILITY FOR <S/C> SAR PAYLOAD
B) DECLARATION OF OPERATION FOR <S/C> SAR PAYLOAD
C) CHANGE IN STATUS FOR <S/C> SAR PAYLOAD
D) DECOMMISSIONING OF <S/C> SAR PAYLOAD
DATA CONSIDERED OPERATIONAL IN COSPAS-SARSAT (WWW.COSPAS-SARSAT.INT)
----------------------------------------------------------------------
(L/G/M)406 SARR: A) OPERATIONAL, B) NOT OPERATIONAL OR C) NOT APPLICABLE
(L) 406 SARP (LOCAL): A) OPERATIONAL OR B) NOT OPERATIONAL
(L) 406 SARP (GLOBAL): A) OPERATIONAL OR B) NOT OPERATIONAL
(L) PSEUDO MODE: A) OPERATIONAL, B) NOT OPERATIONAL OR C) NOT APPLICABLE
STATUS OF SAR PAYLOAD (WWW.COSPAS-SARSAT.INT)
-----------------------------------------------
(L/M) L-BAND DOWNLINK: A) NORMAL, B) DEGRADED, C) UNUSABLE OR D) NOT
APPLICABLE
(Ms)  S-BAND DOWNLINK: A) NORMAL, B) DEGRADED OR C) UNUSABLE
(L/G/M)406 SARR: A) NORMAL, B) DEGRADED, C) UNUSABLE OR D) NOT APPLICABLE
(L/G/M)406 SARR GAIN CONTROL: A) AUTOMATIC, B) FIXED OR C) NOT APPLICABLE
(L) 406 SARP (LOCAL): A) NORMAL, B) DEGRADED OR C) UNUSABLE
(L) 406 SARP (GLOBAL): A) NORMAL, B) DEGRADED OR C) UNUSABLE
(L) PSEUDO MODE: A) ENABLED, B) DISABLED OR C) NOT APPLICABLE
(L/G/M) BANDWIDTH: A) 27 KHZ, B) 40 KHZ, C) 80 KHZ OR D) NOT APPLICABLE
(G) POSITION:
(G) DOWNLINK FREQUENCY/TYPE:
(L) SAR INSTRUMENTS ACTIVE DURING SATELLITE MANOEUVRE: A) YES, B) NO OR C)
NOT APPLICABLE
COMMENTS
(G/M TEST RESULTS PER SPACECRAFT COMMISSIONING STANDARD)
--------
QQQQ
/LASSIT
/ENDMSG
Notes:
(L)
Applies to LEOSAR only.
(G)
Applies to GEOSAR only.
(L/G)
Applies to both LEOSAR and GEOSAR.
(M)
Applies to MEOSAR only
(Ms)
Applies to MEOSAR S-band only
(G/M)
On declaration of Initial Operational Capability, GEOSAR and MEOSAR
commissioning test results shall be reported per documents C/S T.013, Annex D and
C/S T.017, section 5, respectively.
(L/G/M)
Applies to LEOSAR, GEOSAR and MEOSAR.
Figure 5-1: Standard Message for Reporting Satellite Payload Status

5-5

/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 5-2: Standard Message for Reporting Satellite Manoeuvres

5-6

/12345 00000/2270/12 222 1412
/605/2730
TO: ALL MCCS
FROM: FMCC
SUBJECT: REACTIVATION OF THE SARP INSTRUMENT ON [SXX]
THE SARP INSTRUMENT WAS REACTIVATED AT [DD MON YEAR HH:MM]
THE SARP RESUMED NORMAL OPERATIONS AT [DD MON YEAR HH:MM]
NEW SARP TCAL DATA WILL BE SENT AT [DD MON YEAR HH:MM]
WHEN NEW SARP TCAL DATA IS RECEIVED BY THE MCC FOR THIS SATELLITE,
FOLLOW THE PROCEDURE ON SARP REACTIVATION DESCRIBED IN C/S A.001
SECTION 3.6.6. SPECIFICALLY, THE GROUND SEGMENT PROVIDER SHALL:
A) ENSURE THAT THE CALIBRATION TIME IN THE NEW SARP TCAL DATA IS
TREATED AS VALID IN ITS MCC, WITHOUT REGARD TO THE PREVIOUS SARP
TCAL DATA.
B) ENSURE THAT THE NEW SARP TCAL DATA IS USED TO INITIALIZE THE
SARP TCAL DATA IN ITS LEOLUTS, WITHOUT REGARD TO THE PREVIOUS SARP
TCAL DATA.
C) ENSURE THAT ALL DOPPLER SOLUTIONS GENERATED BY ITS LEOLUT(S)
THAT CONTAIN SARP DATA FOR THIS SATELLITE ARE FILTERED UNTIL NEW
SARP TCAL DATA IS LOADED INTO THE ASSOCIATED LEOLUT.
COMMENTS:
QQQQ
/LASSIT
/ENDMSG
[…]
Figure 5-3: Standard Message for Reporting Reactivation of the SARP Instrument

5-7

[…]
/12345 00000/AAA0/12 222 1412
/605/BBB0
TO: ALL MCCS
FROM: <MCC ASSOCIATED WITH THE RELEVANT SPACE SEGMENT PROVIDER >
SUBJECT: SPACECRAFT ANOMALY FOR [XXX]
AN ANOMALY HAS OCCURRED FOR SATELLITE [XXX] AS DESCRIBED BELOW.
[DETAILS OF PROBLEM, INCLUDING START TIME, IF KNOWN]]
WHILE THE IMPACT AND MITIGATION OF THIS ANOMALY ARE BEING EVALUATED,
GROUND SEGMENT PROVIDERS SHOULD:
[…]\*
THE NEXT UPDATE ON THIS ANOMALY IS PLANNED FOR: [DD MON YEAR HH:MM].
QQQQ
/LASSIT
/ENDMSG
Figure 5-4: Standard Message for Reporting a Spacecraft Anomaly
* Message content may vary. For example, the message may include one or more of the following
statements:
A)   EVALUATE THEIR GROUND SYSTEM IN RESPECT OF THIS ANOMALY AND
CONSULT WITH THEIR LUT OR MCC VENDOR, AS APPROPRIATE.
B)   NOTIFY THEIR ASSOCIATED RCCS AND SPOCS THAT [SARR/SARP/YYY]
ALERT DATA FROM THE SATELLITE MAY BE UNRELIABLE.
C)   FILTER [SARR/SARP/YYY] ALERT DATAFROM THE SATELLITE.

5-8

5.3
Description of Cospas-Sarsat MCCs
5.3.1
GENERAL
The purpose of this section is to describe the Cospas-Sarsat MCCs and their interfaces, types of
messages originated, normal routing of these messages, and any backup arrangements with other
MCCs and a list of supported SPOCs. Any general information, such as 406 MHz beacon register
queries, may be included in this section.
Any changes which are unique to the MCC may be amended by that MCC. If bilateral changes are
involved, both MCCs shall draft appropriate amendments to their sections once the new interface
has been successfully tested.
NOTE
Section 5.3 will be updated by Ground Segment Providers with MEOLUT descriptions as
associated MEOLUTs are commissioned for operational use.
Hyperlink to MCC Sections
AEMCC
CMC
KOMCC
SPMCC
ALMCC
CYMCC
MYMCC
TAMCC
ARMCC
FMCC
NIMCC
THMCC
ASMCC
GRMCC
NMCC
TGMCC
AUMCC
HKMCC
PAMCC
TRMCC
BRMCC
IDMCC
PEMCC
UKMCC
CMCC
INMCC
QAMCC
USMCC
CHMCC
ITMCC
SAMCC
VNMCC
CNMCC
JAMCC
SIMCC

5-9

5.3.2
AEMCC - UNITED ARAB EMIRATES MISSION CONTROL CENTRE
Last updated: June 2025
5.3.2.1 AEMCC GENERAL
The UAE Mission Control Centre is manned and operates 24/7. AEMCC operates two Operational
Control Consoles. The primary (AEMCC) is located in Abu Dhabi, in the National Search and
Rescue Center. The secondary (AEMCC2) is a backup to the primary and it is co-located in the
National Search and Rescue Centre in Abu Dhabi.
AEMCC controls one LEOLUT and two GEOLUTs located in Albateen Airbase (Abu Dhabi,
UAE) at the following locations:
Latitude
Longitude
LEOLUT (4701)
24°25.89' N
054° 26.87' E
GEOLUT1 (4702)
24° 25.89' N
054° 26.87' E
GEOLUT2 (4707)
24° 25.89' N
054° 26.87' E
(active-tracking antenna)
AEMCC has been LGM-capable since August 2023. AEMCC also operates a six channel
MEOLUT (4706), commissioned in 2019, located in Albateen Airbase at the following location:
Latitude
Longitude
MEOLUT (4706)
24° 25.89' N
054° 26.87' E
5.3.2.2 SPOCs SUPPORTED
United Arab Emirates.
5.3.2.3 SYSTEM INFORMATION MESSAGES
The following System information messages are received / originated at AEMCC:
•
Orbit vectors:
receive from SPMCC,
•
SARP calibration:
receive from SPMCC,
•
System status:
originate to and receive from SPMCC,
•
Narrative:
received and originated as required.
The communication interfaces used by AEMCC are AFTN and FTP-VPN.
5.3.2.4 BACKUP PROCEDURES AND AGREEMENTS
In the case of complete failure of AEMCC, LGM SPMCC will assume the duties of AEMCC.
LGM SPMCC will send validated Cospas-Sarsat alert data within the AEMCC service area to the
National Search and Rescue Center.

5-10

As described in SPMCC section, AEMCC should follow the procedure for backup termination
when is being backed up by SPMCC:
1.
AEMCC requests backup through the MCC or phone;
2.
SPMCC implements the backup configuration and informs the rest of MCCs via SIT 605;
3.
AEMCC informs SPMCC by phone when they are ready to go back in service, before
starting the distribution of messages;
4.
SPMCC removes the backup configuration and informs all MCCs (including AEMCC)
via SIT 605; and
5.
AEMCC starts transmitting alerts to SPMCC.
Operators will forward a written notice to their backup MCC of intention to perform maintenance
routines requiring a backup at least 24 hours in advance.
As described in SPMCC section, in the case of a complete failure of SPMCC, FMCC will assume
the duties of SPMCC. In that case, AEMCC will change its configuration in order to consider
FMCC as its current nodal MCC until the backup situation is finished. When the backup is finished,
AEMCC will revert to its normal configuration in order to consider SPMCC as its nodal MCC.
5.3.2.5 OTHER INFORMATION
Beacon Registration
Beacon registration is maintained by AEMCC in collaboration with Telecommunications
Regulatory Authority (TRA) for UAE.

5-11

5.3.3
ALMCC - ALGERIAN MISSION CONTROL CENTRE
Last updated: May 2024
5.3.3.1 ALMCC GENERAL
The Algerian Mission Control Centre is located at Algiers. ALMCC controls one LEOLUT , one
GEOLUT and one MEOLUT in Algiers at the following locations:
Latitude
Longitude
Algiers LEOLUT
36° 45.20' N
003° 22.86' E
Algiers GEOLUT
36° 45.20' N
003° 26.87’ E
Algiers MEOLUT
36° 46.2’’ N
003° 22.85' E
The LEOLUT can localise transmitters and distress beacons in local mode and global mode.
Interferers in the 406.0 to 406.1 MHz band are localised in the local mode and this information is
provided to the Algerian Telecommunication for action through the ITU.
The GEOLUT is co-located with the LEOLUT at Algiers, and it operates with MSG-3 satellite.
The MEOLUT is a 4-channel dish antenna.
ALMCC has been LGM-capable (MEOSAR EOC standard) since May 2020.
The SAR Administration is the head agency in Algeria for the Cospas-Sarsat Programme.
5.3.3.2 SPOCs SUPPORTED
ALMCC provides alert data to SPOCs in the ALMCC service area including:
•
Algeria,
•
Burkina Faso,
•
Egypt,
•
Libya,
•
Niger.
It also routes alert messages to SPMCC and can receive these messages from this source.
Alert messages in other DDR service areas are routed to SPMCC.
A communication summary for these interfaces is shown below:
•
Algerian RCC:
AFTN,  fax, voice
•
SPMCC:
FTP-VPN, AFTN, fax, voice
5.3.3.3 SYSTEM INFORMATION MESSAGES
The following System information messages are received / originated at ALMCC:
•
Orbit vectors:
received from SPMCC,
•
SARP calibration:
received from SPMCC,
•
System status:
received and originated as required,

5-12

•
Narrative:
received and originated as required.
5.3.3.4 BACKUP PROCEDURES AND AGREEMENTS
Operators will forward a written notice to their backup MCC of intention to perform maintenance
routines requiring a backup at least 24 hours in advance.
In the case of a complete failure of the ALMCC, SPMCC will assume the duties of ALMCC.
SPMCC will send validated Cospas-Sarsat alert data within the ALMCC service area to designated
SPOCs. In the Algerian SRR this will be Algiers RCC (this AFTN address is DAARYCYF).
As described in SPMCC section, ALMCC should follow the procedure for backup termination
when is being backed up by SPMCC:
1.
ALMCC requests backup through the MCC or phone;
2.
SPMCC implements the backup configuration and informs the rest of MCCs via SIT 605;
3.
ALMCC informs SPMCC by phone when they are ready to go back in service, before
starting the distribution of messages;
4.
SPMCC removes the backup configuration and informs all MCCs (including ALMCC)
via SIT 605; and
5.
ALMCC starts transmitting alerts to SPMCC.
As described in SPMCC section, in the case of a complete failure of SPMCC, FMCC will assume
the duties of SPMCC. In that case, ALMCC will change its configuration in order to consider
FMCC as its current nodal MCC until the backup situation is finished. When the backup is finished,
ALMCC will revert to its normal configuration in order to consider SPMCC as its nodal MCC.
5.3.3.5 OTHER INFORMATION
None.

5-13

5.3.4
ARMCC - ARGENTINE MISSION CONTROL CENTRE
Last updated: May 2024
5.3.4.1 ARMCC GENERAL
The Argentine Mission Control Centre (ARMCC) is located in El Palomar, Buenos Aires.
ARMCC controls two LEOLUTs and one GEOLUT at the following locations:
Latitude
Longitude
El Palomar GEOLUT
34° 36.00' S
058° 36.00' W
Rio Grande LEOLUT
53° 46.75' S
067° 42.32' W
El Palomar LEOLUT
34° 36.00' S
058° 36.00' W
The Argentine LEOLUTs provide full processing of 406 MHz frequency alert data, including
G-SARP processing of the transponded SARR data and combined LEO/GEO processing,
according to the relevant Cospas-Sarsat specifications. The local coverage area of the Argentine
LEOLUTs includes Argentina, South of Brazil and Peru, Bolivia, Paraguay, Uruguay, Chile, part
of Antarctica, the Southwestern Atlantic Ocean and Southeastern Pacific Ocean.
The Argentine GEOLUT receives data from the GOES-East satellite and provides it to the
ARMCC for distribution and to the LEOLUTs for combined LEO/GEO processing.
The communication interfaces available at the ARMCC are AFTN, FTP-PNV, phone and fax.
These communication means are used as follows:
•
ARMCC-USMCC:
FTP-VPN, AFTN-AMHS,
•
ARMCC-RCCs:
AMHS,
•
ARMCC-Falkland Islands (Malvinas)\*:
phone, fax, email,
•
ARMCC-CHMCC:
AFTN-AMHS, email.
The entire ground segment is maintained and operated twenty-four hours a day, seven days a week
by SASS (Servicio de Alerta y Socorro Satelital), a joint Argentine Navy / Air Force office.
Currently, the ARMCC system is non-operational, being supported by CHMCC as long as it
maintains the backup status initiated since June 2023.
5.3.4.2 SPOCs SUPPORTED
ARMCC supports the RCCs in Argentina and Falkland Islands (Malvinas)* SRR.
Despite its current state, the ARMCC continues to serve as the SPOC for the Malvinas / Falkland
Islands * SRR. Alert transmissions are carried out following the standard communication
procedure, based on information received from CHMCC.
Note:
\*
A dispute exists between the Governments of Argentina and the United Kingdom of Great
Britain and Northern Ireland concerning sovereignty over the Falkland Islands (Malvinas).

5-14

5.3.4.3 SYSTEM INFORMATION MESSAGES
ARMCC receives and process the following System information messages:
•
Orbit vectors,
•
SARP calibration data,
•
SARR calibration data,
•
System status,
•
Narrative.
The ARMCC is capable of originating the following System information messages:
•
System status,
•
Narrative.
These messages are normally received from or sent to USMCC.
5.3.4.4 BACKUP PROCEDURES AND AGREEMENTS
The backup procedure described herein is available for the whole Argentine Mission Control
Centre (ARMCC) service area in such a way that the coverage in local mode provided by the
LEOLUT stations of the Chilean Mission Control Centre (CHMCC) overlaps the LEOLUT
coverage of ARMCC.
The procedure whereby the backup service is implemented in case of an unexpected failure or
scheduled interruption of the ARMCC service may occur and is expected to last more than four
(4) hours is as follows:
CHMCC sends Cospas-Sarsat alerts data to ARMCC over AFTN-AMHS.
During scheduled or unscheduled ARMCC outages, incoming AFTN-AMHS data is re-routed to
appropriate RCCs using the SIT 185 format as defined in the C/S A.002 document.
hen this procedure is implemented, the ARMCC’s personnel will communicate with national
RCCs (maritime and aeronautical) and inform them that CHMCC provides the distribution of
distress alerts from the Cospas-Sarsat system. ARMCC continues to analyze and monitor the alert,
based on messages transmitted by CHMCC via e-mail/AFTN, and retransmitting to the relevant
RCC.
ARMCC will attempt to pass them to its service area RCCs/SPOCs by manually “geosorting” them
and using the AFTN-AMHS link communication, fax and/or other alternative links.
The backup procedures for ARMCC consist of the following steps:
a.
Whenever backup service is required, ARMCC notifies CHMCC, requesting them to provide
the backup service. The requirement is voice-transmitted to CHMCC by ARMCC and
confirmed by means of email or fax to CHMCC and USMCC.
b.
CHMCC notifies USMCC and ARMCC when the backup service is being provided.

5-15

c.
USMCC notifies CHMCC and ARMCC when the backup service is being provided. During
the backup service provision, USMCC sends to CHMCC the messages for and to be
forwarded to ARMCC. USMCC will hold the messages intended for ARMCC for re-
transmission upon request.
d.
USMCC notifies all MCCs of the start of the backup service by means of a SIT 605 message
(as established in C/S A.001, section 3.6).
e.
ARMCC sends a SIT 605 message when the ARMCC normal service is restored.
f.
USMCC sends a SIT 915 message to ARMCC and CHMCC notifying them that data
distribution to/from ARMCC is back to normal.
g.
CHMCC sends a SIT 915 message to ARMCC and USMCC notifying them that data
distribution to/from ARMCC is back to normal.
Since June 2023, ARMCC has been backed up by CHMCC, receiving distress alerts via AFTN
and/or email. ARMCC continues to analyze and track the alerts based on the messages transmitted
by CHMCC and relays them to the corresponding RCC.
5.3.4.5 OTHER INFORMATION
The beacon database is maintained by the ARMCC and register the national beacons in the IBRD.
LGM implementation:
Argentina has installed the MEOLUT equipment, establishing a MEOLUT system with six (6)
antennas at the following locations:
Latitude
Longitude
El Palomar MEOLUT (4 antennas)
34° 36.00' S
058° 36.00' W
Rio Grande MEOLUT
(2 antennas)
53° 46.75' S
067° 42.32' W
The bidding process is underway to implement the G-M integrated system in the short term..

5-16

5.3.5
ASMCC - SOUTH AFRICAN MISSION CONTROL CENTRE
Last updated: October 2023
5.3.5.1 ASMCC GENERAL
The South African Mission Control Centre is located in Milnerton (Cape Town). ASMCC controls
one LEOLUT with G-SARP. This LEOLUT is located at:
Latitude
Longitude
33° 52.80' S
018° 30.00' E
The South African MCC and LEOLUT operate 24 hours a day throughout the year.
The Maritime division of Telkom SA is responsible for the operation of the South African MCC
and LEOLUT.
5.3.5.2 SPOCs SUPPORTED
Angola
Eswatini
Namibia
Uganda
Botswana
Lesotho
Rwanda
Zambia
Burundi
Malawi
South Africa
Zimbabwe
Democratic Republic of Congo
Mozambique
St. Helena
The communication interfaces used by the ASMCC are:
•
AFTN, FTP-VPN.
5.3.5.3 SYSTEM INFORMATION MESSAGES
The ASMCC originates and receives the following System information:
•
Orbit vectors:
receive from AUMCC,
•
SARP calibration:
receive from AUMCC,
•
System status:
originate and receive from AUMCC.
5.3.5.4 BACKUP PROCEDURES AND AGREEMENTS
In the event ASMCC becomes unserviceable, AUMCC will provide backup support to ASMCC.
All alerts for the ASMCC service area will be transmitted on SIT 185 format and faxed to a number
nominated by ASMCC. ASMCC will ensure distribution to the RCCs it supports.
5.3.5.5 OTHER INFORMATION
None.

5-17

5.3.6
AUMCC - AUSTRALIAN MISSION CONTROL CENTRE
Last updated: May 2024
5.3.6.1 AUMCC GENERAL
The Australian Mission Control Centre is located  in Canberra.
AUMCC receives alert data from the Goudies Road GEOLUTs (NZGEO1 - ID: 5123 and
NZGEO2 - ID: 5124), the Mingenew MEOLUT (ID: 5035), and the Taupō MEOLUT (ID: 5125)
and distributes them in accordance with this document. The Mingenew and Taupō MEOLUTs are
networked with coordinated satellite scheduling. All four LUTs operate 24 hours a day throughout
the year.
AUMCC operates 24 hours a day throughout the year providing alert data through the RCCs and
SPOCs in accordance with this document.
AUMCC also assumes the nodal responsibilities for the Southwest Pacific DDR as defined at
section 4.1 of this document.
The Australian Maritime Safety Authority (AMSA) is responsible for the management and
operation of the Australian Cospas-Sarsat ground segment.
5.3.6.2 SPOCs SUPPORTED
AUMCC, in supporting its service area, passes alerts to the following SRRs: Australia, New
Zealand, Papua New Guinea, Solomon Islands and Fiji.
AUMCC distributes Notification of Country of Registration (NOCR) and unlocated alerts
according to the following table:
Country
Associated
MCC
MID
NOCR Transmitted To
Unlocated Transmitted To
Adelie Land
AUMCC

FMCC
JRCC Australia & FMCC
Australia
AUMCC

JRCC Australia
JRCC Australia
New Zealand
AUMCC

JRCC NZ
JRCC NZ
Christmas Island
AUMCC

JRCC Australia
JRCC Australia
Cook Islands
AUMCC

JRCC NZ
JRCC NZ
Fiji
AUMCC

Fiji RCC
Fiji RCC
Cocos (Keeling) Islands
AUMCC

JRCC Australia
JRCC Australia
Kiribati
AUMCC

Fiji RCC
Fiji RCC
New Caledonia
AUMCC

New Caledonia RCC & FMCC
New Caledonia RCC & FMCC
Niue
AUMCC

JRCC NZ
JRCC NZ
Nauru
AUMCC

Solomon Islands RCC
Solomon Islands RCC
Papua New Guinea
AUMCC

PNG RCC
PNG RCC
Solomon Islands
AUMCC

Solomon Islands RCC
Solomon Islands RCC

5-18

Country
Associated
MCC
MID
NOCR Transmitted To
Unlocated Transmitted To
American Samoa
AUMCC

JRCC NZ
JRCC NZ
Samoa
AUMCC

JRCC NZ
JRCC NZ
Tonga
AUMCC

JRCC NZ
JRCC NZ
Tuvalu
AUMCC

Fiji RCC
Fiji RCC
Vanuatu
AUMCC

New Caledonia RCC & VAPOC¹
New Caledonia RCC & VAPOC
Vanuatu
AUMCC

New Caledonia RCC & VAPOC
New Caledonia RCC & VAPOC
Wallis and Futuna Islands
AUMCC

New Caledonia RCC & FMCC
New Caledonia RCC and FMCC
Saint Paul and Amsterdam
Islands
AUMCC

FMCC
JRCC Australia & FMCC
(1) VAPOC = Vanuatu Point of Contact
5.3.6.3 SYSTEM INFORMATION MESSAGES
AUMCC originates, receives and forwards System Information messages as follows:
•
Orbit vectors:
receive from CMC, JAMCC and USMCC and forward to ASMCC,
IDMCC, SIMCC and THMCC.
•
SARP calibration:  receive from FMCC and forward to ASMCC, IDMCC, SIMCC and
THMCC.
•
System status:
originate, receive and forward from/to ASMCC, CMC, FMCC,
IDMCC, JAMCC, SIMCC, SPMCC, THMCC and USMCC.
5.3.6.4 BACKUP PROCEDURES AND AGREEMENTS
The Australian and New Zealand MEOLUTs provide partial backup for each other as there is some
overlapping local mode coverage. The networked MEOLUTs can operate in standalone mode in
the event a coordinated schedule is not available.
Goudies Road GEOLUTs 1 and 2 provide alternative coverage over the area of AU-SRR and
NZ-SRR.
An agreement is in place with USMCC to provide backup of the AUMCC nodal responsibility.
The following procedure has been agreed to:
In the event of a failure of nodal AUMCC, the duty personnel will:
a.
contact USMCC and advise them to assume AUMCC nodal responsibilities;
b.
request USMCC to transmit AUMCC service area alerts in SIT 185 format. AUMCC will
attempt to pass them to its service area RCCs/SPOCs by manually geosorting them and using
the RCC communication modes available; and
c.
advise USMCC that alerts from the local Australian or New Zealand MEOLUTs and
GEOLUTs will be passed by the RCC in some form on a ‘best effort’ basis.

5-19

It should be noted that RCC/AUMCC has 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. This
alternate site is already set up to support most of the RCC functions and some AUMCC functions.
5.3.6.5 OTHER INFORMATION
Registration of Beacons
A register for Australian, Cocos Island and Christmas Island beacons is maintained by AMSA.
Country codes supported by Australian registry:
COUNTRY CODE: COUNTRY NAME:

Australia

Christmas Island

Cocos (Keeling) Islands

5-20

5.3.7
BRMCC - BRAZILIAN MISSION CONTROL CENTRE
Last updated: June 2025
5.3.7.1 BRMCC GENERAL
The Brazilian Mission Control Centre (BRMCC) operates two Operational Control Consoles
(OCCs). The first one as primary OCC located in Brasilia, the second one as secondary OCC being
a backup facility co-located with ARCC-RE in Recife. Two LEOLUTs are located at Brasilia and
Recife; BRMCC MEOLUTs have twelve antennas that track MEOSAR satellites, six in Brasília
(one channel) and six in Recife (one channel. The BRMCC also operates two GEOLUTs at Brasilia
and Recife. The coordinates of these LUTs are as follows:
LEOLUTs:
Latitude
Longitude
Brasilia
15° 51.43' S
047° 54.16' W
Recife
08° 08.30' S
034° 55.50' W
GEOLUTs:
Brasilia
15° 51.43' S
047° 54.16' W
Recife
08° 08.30' S
034° 55.50' W
MEOLUTs:
Brasília
15º 51.43' S
047º 54.12' W
Recife
08º 08.18' S
034º 55.85' W
All Brazilian LEOLUTs can localise 406 MHz distress beacons in local and global coverage mode
also Brazilian LEOLUTs can process 406 MHz interference data in local coverage mode.
The local mode coverage of the Brazilian LEOLUTs includes the central part of South America
and western area of South Atlantic Ocean.
Brazilian MEOLUTs are commissioned, and BRMCC has been LGM-capable since January 2025.
The BRMCC, GEOLUTs and LEOLUTs operate 24 hours a day throughout the year.
The communication interfaces used by BRMCC are AFTN, FTP-VPN, voice and fax.
5.3.7.2 SPOCs SUPPORTED
BRMCC provides primary support to the Brazilian RCCs and Ascension Island and routes alert
and notification (NOCR) messages to other countries and can receive these messages from them.
5.3.7.3 SYSTEM INFORMATION MESSAGES
BRMCC originates and receives the following System information:
•
Orbit vectors:
receive from USMCC,

5-21

•
SARP calibration:
receive from USMCC,
•
System status:
originate to and receive from USMCC,
•
406 MHz SARR frequency calibration:
receive from USMCC.
5.3.7.4 BACKUP PROCEDURES AND AGREEMENTS
Brasilia and Recife LUTs have overlapping local mode coverage areas to a greater or lesser extent
with the following LEOLUTs: Callao, Florida and Santiago. It is therefore feasible for the
Brazilian area to be partly covered in the case of failure or planned maintenance downtime.
BRMCC operates two Operational Control Consoles (OCCs). The first one as primary OCC
located in Brasilia, the second one as secondary OCC being a backup facility co located with
ARCC-RE in Recife.
In the event of failure of primary OCC, Brazil has backup agreements and procedures in place with
the USA. The following procedures have been agreed to:
a)
BRMCC (from Brasilia) notifies USMCC whenever the backup service is required by means
of fax, phone or email;
b)
USMCC notifies BRMCC (Brasilia) when the backup service commences by fax, phone or
email. In case of failure of these contacts, USMCC shall notify BRMCC (Recife), as contact
list bellow;
c)
USMCC sends a SIT 605 message notifying the other MCCs of the BRMCC failure, and
that USMCC is performing backup service according to section 3.7, document C/S A.001;
d)
USMCC transmits alert messages or status messages, as appropriate, for the Brazilian service
area to ARCC-RE using the BRMCC OCC-2 AFTN address (primary communication link)
or via FTP-VPN link;
e)
in the event that USMCC is unable to communicate with BRMCC (OCC-2 Recife) as
described in (d) above, USMCC shall transmit alerts for the Brazilian service area in SIT 185
format to the Brasilia ARCC (ARCC-BS) AFTN address (primary communication link) or
via fax. In this case, USMCC will advise the ARCC-BS of their inability to communicate
with BRMCC (OCC-2 Recife). Other Brazilian ARCCs as well as BRMCC (Brasilia) will
be advised by ARCC-BS;
f)
BRMCC (from Recife) advises the Brazilian ARCCs about the BRMCC failure and about
the backup procedures;
g)
BRMCC (from Brasilia or Recife) will notify USMCC as soon as the problem is solved, and
will advise the time when BRMCC (Brasilia) plans to restore normal operations;
h)
when BRMCC (Brasilia) returns to normal operations it will send a SIT 605 message
notifying USMCC and other MCCs that BRMCC (Brasilia) has resumed normal operations;
and
i)
USMCC will send all requested missing messages to BRMCC (Brasilia) using the contact
lists available at https://www.cospas-sarsat.int/.

5-22

5.3.7.5 OTHER INFORMATION
A register for Brazilian beacons is maintained by BRMCC and Department of Air Space Control
(DECEA). The link to the website is https://infosar.decea.mil.br.

5-23

5.3.8
CMCC - CANADIAN MISSION CONTROL CENTRE
Last updated: May 2024
5.3.8.1 CMCC GENERAL
The Canadian Mission Control Centre is located in Trenton, Ontario and maintains a backup
facility and CMCC server in Belleville, Ontario.
Canada has the following commissioned LUTs:
LEOLUTs:
•
Churchill, Manitoba,
•
Edmonton, Alberta,
•
Goose Bay, Labrador,
•
Ottawa, Ontario (test / backup facility),
GEOLUTs:
•
Edmonton, Alberta,
•
Ottawa (1), Ontario (test / backup facility),
•
Ottawa (2), Ontario,
MEOLUTs (will be connected to operational system once LGM CMCC is commissioned):
•
Edmonton, Alberta,
•
Goose Bay, Labrador,
•
Trenton, Ontario,
•
Belleville, Ontario.
Locations are provided on www.cospas-sarsat.int.
The LEOLUTs provide full coverage of Canadian SRRs from mid-Atlantic to the Gulf of Alaska
and from the North Pole south to approximately 30 degrees north latitude. Operations are 24 hours
per day, seven (7) days per week.
The communication interfaces used by the CMCC are:
•
Canadian RCCs:
FTP, voice, fax, email
•
LUTs to CMCC:
FTP, SFTP
•
USMCC:
FTP-VPN, AFTN, voice, fax,
•
AUMCC (as part of USMCC backup): FTP-VPN, AFTN, voice, fax.
5.3.8.2 SPOCs SUPPORTED
CMCC has no SPOCs in its service area. However, CMCC provides primary support to three
Canadian Joint Rescue Coordination Centres (JRCC Victoria, JRCC Trenton and JRCC Halifax)
and two Canadian Maritime Rescue Sub-Centres (MRSC Quebec, and MRSC St  ohn’s), and

5-24

through JRCC Halifax to Saint-Pierre and Miquelon (French Islands off the south coast of
Newfoundland).
CMCC distributes unlocated and NOCR alerts for Saint-Pierre-et-Miquelon to FMCC through
USMCC. On a national level to assist the coordination between MRCC Gris-Nez and JRCC
Halifax, CMCC also sends Saint-Pierre-et-Miquelon unlocated alerts to JRCC Halifax.
5.3.8.3 SYSTEM INFORMATION MESSAGES
Canada originates and receives the following System information messages:
•
SARR command:
originate to USMCC,
•
SARR command verification:
receive from USMCC,
•
SARR frequency calibration offset:
originate to USMCC,
•
System Status:
originate and receive, as required,
•
Narrative:
originate and receive, as required,
•
Orbit Vectors:
receive via USMCC,
•
SARP calibration:
receive via USMCC.
5.3.8.4 BACKUP PROCEDURES AND AGREEMENTS
The L Ts operated by CMCC and  SMCC provide overlapping coverage of each other’s areas
of responsibility.
In the event of a complete CMCC failure, Canada has a backup agreement and procedure in place
with USMCC. USMCC would route alert data directly to appropriate Canadian JRCCs and
MRSCs.
In the event of a USMCC failure, USMCC has a backup agreement and procedure in place with
CMCC and AUMCC. CMCC would assume USMCC national Sarsat responsibility and send alerts
directly to the appropriate US RCCs and SPOCs. For alerts outside the USMCC SRR, CMCC will
send alerts via FTP-VPN or AFTN to AUMCC, as AUMCC assumes nodal responsibilities for
USMCC. USMCC provides CMCC with the current geosort data for its national RCCs and SPOCs.
Canada has installed a completely functional backup system for CMCC at Belleville, Ontario. In
the event of the need to transition to this alternate location, CMCC would inform USMCC as soon
as possible. Once all communication links have been reconfigured, operation of the backup site
would be transparent to external MCCs/agencies.
CMCC will initiate a communications test once per quarter with AUMCC and all US RCCs. These
communications tests are to test both modes of communications (FTP-V/AFTN), using direct
routing to / from AUMCC, to ensure that these routes are operational in the event MCC Backup
Procedures are required.

5-25

5.3.8.5 OTHER INFORMATION
Registration of Beacons
A register for Canadian beacons is maintained by the Canadian Beacon Registry, located at CMCC
in Trenton, Canada. The website is www.cbr-rcb.ca. CMCC duty operators have 24/7 access to
the CBR website for the retrieval of registration data upon request.

5-26

5.3.9
CHMCC - CHILEAN MISSION CONTROL CENTRE
Last updated: June 2025
5.3.9.1 CHMCC GENERAL
The Chilean Mission Control Centre is located in Los Cerrillos, Santiago. CHMCC controls one
MEOLUT, three LEOLUTs and one GEOLUT at the following locations:
Latitude
Longitude
MEOLUT:
Santiago
33 33.32' S
070 41.30' W
LEOLUTs:
Punta Arenas
53 00.36' S
070 50.82' W
Santiago
33 29.70' S
070 42.24' W
Easter Island
27 09.01' S
109 26.22' W
GEOLUT:
Santiago
33 29.70' S
070 42.24' W
All Chilean LEOLUTs can localize 406 MHz distress beacon alerts in local and global coverage
mode.
The Chilean MEOLUT (7255) is composed of six antennas that are installed at Santiago, Chile.
The local mode coverage of the Chilean LEOLUTs covers the areas of Chile, Argentina, Bolivia,
Paraguay, Uruguay, part of Brazil, Peru, Pacific Ocean and Antarctica.
The CHMCC, MEOLUT, LEOLUTs and GEOLUT operate 24 hours a day throughout the year.
The Chilean Air Force (FACH) is responsible for the operation of the Chilean MCC, MEOLUT,
LEOLUTs and GEOLUT.
The communication interfaces used by the CHMCC are:
•
Chilean RCCs
FTP-VPN, AMHS, phone, email,
•
SPOCs
AMHS, phone, email (Bolivia. Uruguay y Paraguay),
•
Chilean MRCC
FTP-VPN, phone, fax, email,
•
USMCC
FTP-VPN, AMHS, phone, email (nodal).
CHMCC has been LGM-capable since November 2020.

5-27

5.3.9.2 SPOCs SUPPORTED
The Chilean Mission Control Centre receives alert data from the MEOLUT, LEOLUTs and
GEOLUT and from other Cospas-Sarsat MCCs in accordance with document C/S A.001. It
provides Cospas-Sarsat alert data to the following countries (SPOCs):
•
Bolivia,
•
Paraguay,
•
Uruguay,
5.3.9.3 SYSTEM INFORMATION MESSAGES
The following System information messages are received / originated at CHMCC:
•
Orbit vectors:
received from USMCC,
•
SARP calibration:
received from USMCC,
•
System status:
received and originated as required,
•
Narrative:
received and originated as required.
5.3.9.4 BACKUP PROCEDURES AND AGREEMENTS
In the unlikely event of a CHMCC failure, Chile has backup agreements and the following
procedures in place with the USA:
a.
CHMCC shall notify USMCC by phone or email when the back service is required.
b.
USMCC shall notify CHMCC by phone or email when the backup service commences.
c.
USMCC shall send a SIT 605 message notifying the other MCCs of the failure of CHMCC
and that USMCC is performing backup service according to section 3.7 of document
C/S A.001.  SMCC shall also notify the CHMCC’s SPOCs of the same information by SIT
915 message.
d.
The data distribution procedures and formats during the backup are the follows:
If the alert message is located within Chile’s search and rescue area, all messages shall be
sent by USMCC directly to Santiago RCC (AMHS address SCTIYCYX), using a SIT 185
message.
If the alert message is located within the search and rescue area of any of the Chilean’s
SPOCs (Bolivia, Paraguay and Uruguay), USMCC shall send the alert message directly to
the SPOC where the alert has been located, using a SIT 185 message.
The AMHS addresses for the Chile’s SPOCs are:
•
Bolivia (BOLISPOC: SLLPZRZX),
•
Paraguay (PARASPOC: SGASSARX),
•
Uruguay (URUGSPOC: ZUMUYCYX).
e.
Once the failure is overcome, CHMCC shall notify USMCC and other MCCs that CHMCC
has resumed normal operations using a SIT 605 message. CHMCC shall also notify its
SPOCs that it has resumed normal operations by a SIT 915 message.

5-28

f.
By default, USMCC shall send all held system information messages (including SIT 605,
215, 216 and 417 messages) and all held alert messages within the Chilean Service Area to
CHMCC when CHMCC resumes its normal operation.
5.3.9.5 OTHER INFORMATION
Beacon Registration
A 406 MHz EPIRBs/ELTs have been approved for carriage on Chilean vessels and aircraft. A
database of Chilean registered Cospas-Sarsat maritime beacons is maintained by the General
Directorate of Maritime Territory and Merchant Marine, and another database of Chilean
registered Cospas-Sarsat aviation beacons is maintained by the General Directorate of Civil
Aviation. CHMCC also maintains a copy of the Chilean register for Cospas-Sarsat aviation
beacons.

5-29

5.3.10 CNMCC - CHINESE MISSION CONTROL CENTRE
Last updated: June 2025
5.3.10.1 CNMCC GENERAL
The Chinese Mission Control Centre is co-located with the China Maritime Search and Rescue
Centre and controls two LEOLUTs and one 6-channel MEOLUT installed at the Ministry of
Communications at the following location:
Latitude
Longitude
39° 54.30' N
116° 25 00.05' N
The local mode of the Chinese LEOLUTs covers the main land of China, the East China Sea, the
Yellow Sea and the part of the South China Sea.
Both LEOLUTs can locate transmitters and distress beacons in local mode as well as global mode.
The Beijing (1) LEOLUT includes a Ground Search and Rescue Processor (G-SARP) to process
the repeater band. The Beijing (2) LEOLUT is used as a backup of Beijing (1).
CNMCC, the MEOLUT and LEOLUTs operate 24 hours a day throughout the year and provide
alert data to Chinese RCCs and to SPOCs within the CNMCC service area in accordance with
document C/S A.001 and national procedures.
5.3.10.2 SPOCs SUPPORTED
CNMCC provides primary support to Chinese RCCs.
The communication interfaces used by CNMCC are:
•
AFTN
FTP-PNV, voice, fax.
5.3.10.3 SYSTEM INFORMATION MESSAGES
The following System information is received / originated at CNMCC:
•
Orbit vectors:
originate to JAMCC and receive from JAMCC,
•
SARP calibration:
receive from JAMCC,
•
System status:
originate to and receive from JAMCC.
5.3.10.4 BACKUP PROCEDURE AND AGREEMENTS
The LEOLUTs at Beijing, Incheon, Nakhodka, among others, have overlapping local mode
coverage areas. It is therefore feasible for one to backup the other in case of failure or planned
maintenance downtime. Co operation in the coverage of individual satellites passes may also be
feasible in the future.
In the unlikely event of a CNMCC failure, China has backup agreements with Hong Kong.

5-30

5.3.10.5 OTHER INFORMATION
A register of maritime EPIRBs is maintained at China Transport Telecommunications Centre. The
CNMCC is able to get access to the register.

5-31

5.3.11 CMC - COSPAS MISSION CENTRE
Last updated: May 2024
5.3.11.1 CMC GENERAL
The Cospas Mission Centre (i.e., the Russian Mission Control Centre) is located in Moscow and
controls seven national LUTs at the following locations:
Latitude
Longitude
LEOLUT-2731 Moscow\*
55° 37.30' N
037° 30.63' E
GEOLUT-2732 Khabarovsk (2)
48° 28.03’ N
135° 21.16’ E
LEOLUT-2733 Nakhodka
42° 51.52' N
132° 47.44' E
GEOLUT-2735 Moscow (1)
55° 44.60' N
037° 43.36' E
GEOLUT-2736 Moscow (2)
55° 44.88’' N
037° 43.39' E
GEOLUT-2738 Khabarovsk (1)
48° 28.05’ N
135° 21.09’ E
GEOLUT-2739 Krasnoyarsk
56° 15.89’ N
093° 30.95’ E
Note: * Under development.
LEOLUTs can localise transmitters and distress beacons in local mode and global mode.
The local mode coverage of the Russian LEOLUTs includes Europe, northern and central parts of
Asia, western part of North Pacific, north-eastern part of Africa.
The Russian LGM MCC, GEOLUTs and LEOLUTs operate 24 hours per day throughout the year.
LGM CMC also assumes the nodal responsibilities for the Eastern DDR as defined at section 5.3
of this document.
The agency Morsviazsputnik is responsible for operation of the Russian LGM MCC, GEOLUTs
and LEOLUTs.
5.3.11.2 SPOCs SUPPORTED
CMC service area includes the territory of:
•
Armenia,
•
Azerbaijan,
•
Belarus,
•
Bulgaria,
•
Czech Republic,
•
Hungary,
•
Kazakhstan,
•
Kyrgyz Republic,
•
Moldova,
•
Mongolia,
•
Romania,
•
Russia,
•
Slovakia,
•
Tajikistan,
•
Turkmenistan,
•
Uzbekistan.
Note: There is an overlap with the TRMCC service area over Georgia and Ukraine.

5-32

The CMC routes alert data to RCCs of the Russian Federation and to other States in its service
area and to the AUMCC, FMCC, INMCC, JAMCC, PAMCC, SPMCC and USMCC in accordance
with the document C/S A.001 (DDP).
The following communication lines are used by the CMC:
•
Russian RCCs:
PSTN (Public Switched phone Network) communications, fax,
•
Russian LUTs:
FTP, PSTN communications,
•
AUMCC:
FTP-VPN, AMHS,
•
FMCC:
FTP-VPN, AMHS,
•
INMCC:
FTP-VPN, AMHS,
•
JAMCC:
FTP-VPN, AMHS,
•
PAMCC:
FTP-VPN, AMHS,
•
SPMCC:
FTP-VPN, AMHS,
•
USMCC:
FTP-VPN, AMHS.
5.3.11.3 SYSTEM INFORMATION MESSAGES
The CMC originates and receives the following System information messages:
•
Orbit vectors:
originate to AUMCC, FMCC, INMCC, JAMCC, PAMCC, SPMCC
and USMCC and receive from USMCC, and JAMCC,
•
SARP calibration: receive from FMCC, forward to INMCC and PAMCC,
•
System status:
originate to and receive from AUMCC, FMCC, INMCC, JAMCC,
PAMCC, SPMCC and USMCC.
5.3.11.4 BACKUP PROCEDURES AND AGREEMENTS
In the case of complete failure of the CMC, the FMCC will assume the duties of the CMC. FMCC
will send validated Cospas-Sarsat alert data to INMCC and PAMCC, and within the CMC service
area to designated SPOCs or RCCs.
5.3.11.5 OTHER INFORMATION
Beacon Registration
A register on national units equipped with beacons is maintained at the CMC.

5-33

5.3.12 CYMCC - CYPRUS MISSION CONTROL CENTRE
Last updated: November 2022
5.3.12.1 CYMCC GENERAL
The Cyprus Mission Control Centre (CYMCC) is located at Larnaca, Cyprus. CYMCC is
associated with the Larnaca EU MEOLUT.
The MEOLUT is located at the following co-ordinates:
Latitude
Longitude
Larnaca MEOLUT 2091
34º 51.90ʹ N
033º 23.02ʹ E
CYMCC and MEOLUT operate 24 hours a day throughout the year.
The communication interfaces used by CYMCC are as follows:
•
FTP-VPN, AFTN. fax, voice.
5.3.12.2 SPOCs SUPPORTED
CYMCC provides primary support to JRCC Larnaca and routes alert and notification (NOCR)
messages to other countries and can receive these messages from them.
5.3.12.3 SYSTEM INFORMATION MESSAGES
The following System information messages are received/originated at CYMCC:
•
System status:
originate and receive as required,
•
Narrative:
as required,
•
Orbit vectors:
receive via FMCC,
•
SARP calibration: receive via FMCC.
5.3.12.4 BACKUP PROCEDURES AND AGREEMENTS
CYMCC operates two (2) Mission Control Centres (MCCs), one of them being a backup. In the
event of failure of both MCCs, Cyprus has backup agreements and procedures in place with Italy.
The following procedures have been agreed to:
a)
Whenever the backup service is required, CYMCC notifies the ITMCC by means of fax,
phone or email.
b)
ITMCC notifies CYMCC when the backup service commences by fax, phone or email.
c)
ITMCC sends a SIT 605 message notifying all other MCCs of the CYMCC failure and that
ITMCC is performing backup service according to section 3.7, document C/S A.001.
d)
CYMCC advises JRCC Larnaca about the CYMCC failure and about the backup procedures.

5-34

e)
ITMCC transmits alerts for the Cyprus service area in SIT 185 format to JRCC Larnaca
using the AFTN network (primary communication link) or via fax.
f)
In the event that ITMCC is unable to communicate with JRCC Larnaca as described above,
ITMCC shall transmit alerts for the CYMCC service area in SIT 185 format to JRCC
Larnaca via satellite fax and satellite telephone.
g)
CYMCC will notify ITMCC about the problem status and will advise the time when
CYMCC plans to restore normal operations.
h)
When CYMCC returns to normal operations it will send a SIT 605 message notifying
ITMCC and other MCCs that CYMCC has resumed normal operations. CYMCC will also
notify JRCC Larnaca that it has resumed normal operations.
i)
ITMCC will send all requested missing messages to CYMCC and will notify it about the
events handled during the backup.
j)
ITMCC shall contact CYMCC using the contact lists available at www.cospas-sarsat.int.
Note: Address to JRCC (co-located with CYMCC) until finalization of communication details.
k)
ITMCC shall contact JRCC Larnaca using the contact lists available at www.cospas-
sarsat.int.
l)
CYMCC shall contact ITMCC using the contact lists available at www.cospas-sarsat.int.
5.3.12.5 OTHER INFORMATION
Beacon Registration
CYMCC has access 24/7 to all Cypriot beacon registries (EPIRBs, ELTs and PLBs with country
codes 209, 210 and 212).
Registration of EPIRBs is provided by the Department of Merchant Shipping, Cyprus.
Registration of ELTs is provided by the Department of Civil Aviation, Cyprus.
Registration of PLBs is provided by JRCC Larnaca.
Location of CYMCC
CYMCC is collocated with JRCC Larnaca.

5-35

5.3.13 FMCC - FRENCH MISSION CONTROL CENTRE
Last updated: June 2025
5.3.13.1 FMCC GENERAL
The LGM French Mission Control Centre is co-located with dual LEOLUTs, one GEOLUT and
one MEOLUT in Centre National d'Études Spatiales (CNES) technical centre in Toulouse. The
French Administration (Civil Aviation and Maritime Affairs) is responsible for validation and
transmission of alert data to MCCs and SPOCs, in accordance with C/S A.001 and national
procedures.
The FMCC also assumes the nodal responsibilities for the Central DDR as defined at section
4.1.4.2 of this document.
The French Mission Control Centre receives alert data from the Toulouse dual LEOLUT,
GEOLUT and MEOLUT and from La Réunion MEOLUT, and from other Cospas-Sarsat MCCs
in accordance with the document C/S A.001.
AFTN and FTP-VPN are used for communication with other MCCs. AFTN, FTP-VPN and email
are used for communication with the supported SPOCs.
The LEOLUTs are equipped with dedicated antennas which makes possible tracking of all Cospas-
Sarsat satellites passing over Toulouse, unless two satellites are in conflict (i.e., pass at the same
time). The dual LEOLUTs can localise transmitters and distress beacons in both the global and
local modes. Interferers in the 406.0 MHz to 406.1 MHz frequency band are localised in the local
mode and this information is provided to the French Telecommunication Administration for action
through ITU. The Toulouse LEOLUTs provide local mode coverage of Europe, eastern half of
North Atlantic and Africa to latitude 20 degrees North.
The French GEOLUT points to MTG-I1satellite.
The Toulouse MEOLUT 2275 deployed in November 2018 is a phase-array antenna located on
the Toulouse site. MEOLUT 2275 tracks and processes MEOSAR L-band (using the phase-array
antenna signals) satellites. All the RF signals are gathered together in a single signal processing
server for alert generation.
The La Réunion MEOLUT 6601 deployed in November 2020 and commissioned in October 2022
is a phase-array antenna located in Rivière-des-Pluies, La Réunion, France. MEOLUT (6601)
tracks and processes MEOSAR L-band (using the phase-array antenna signals) satellites. All the
RF signals are gathered in a single signal processing server for alert generation.
For the provision of the Return Link Service, an interface has been implemented between the
French MCC (FMCC), representing the Cospas-Sarsat System, and the Return Link Service
Provider (RLSP) for Galileo.

5-36

5.3.13.2 SPOCS AND COUNTRIES SUPPORTED
FMCC provides Cospas-Sarsat alert data to the following SPOCs and countries:
Country
SPOC
Remarks
Andorra
France is SPOC for Andorra
Anguilla
Martinique is SPOC for Anguilla
Antigua and Barbuda
Martinique is SPOC for Antigua and Barbuda
Austria
X
Azores
Portugal is SPOC for Azores
Belgium
X
Chad
X
Comoros
La Réunion is SPOC for Comoros
Crozet Archipelago
La Réunion is SPOC for Crozet Archipelago
Djibouti
X
Dominica
Martinique is SPOC for Dominica
France
X
French Polynesia
X
Germany
X
User state
Gibraltar
X
Guadeloupe
Martinique is SPOC for Guadeloupe
Guiana
Martinique is SPOC for Guiana
Kerguelen Islands
La Réunion is SPOC for Kerguelen Islands
Liechtenstein
Switzerland is SPOC for Liechtenstein
Luxemburg
X
Madagascar
X
Madeira
Portugal is SPOC for Madeira
Martinique
X
Mauritius
X
Mayotte
La Réunion is SPOC for Mayotte
Monaco
X
France is SPOC for Monaco
Montserrat
Martinique is SPOC for Montserrat
Morocco
X

5-37

Country
SPOC
Remarks
Netherlands
X
User State
Pitcairn
French Polynesia is SPOC for Pitcairn
Portugal
X
La Réunion
X
Saint Kitts and Nevis
Martinique is SPOC for Saint Kitts and Nevis
Saint Lucia
Martinique is SPOC for Saint Lucia
Surinam
X
Switzerland
X
User State
Tunisia
X
User State
Cospas-Sarsat alerts localised inside the FMCC service area are forwarded to the responsible
SPOC or RCC.
5.3.13.3 SYSTEM INFORMATION MESSAGES
The following System information messages are received / originated at FMCC:
•
SARP command:
originate to USMCC,
•
SARP command verification:  receive from USMCC,
•
System status:
originate and receive as required,
•
Narrative:
as required,
•
Orbit vectors:
receive from CMC, USMCC, and JAMCC, and forward
to CYMCC, GRMCC, ITMCC, NMCC, TRMCC, and
UKMCC,
•
SARP calibration:
originate to AUMCC, CMC, CYMCC, ITMCC,
JAMCC,
NMCC,
SPMCC,
UKMCC,
GRMCC,
TRMCC and USMCC.
5.3.13.4 BACKUP PROCEDURES AND AGREEMENTS
LUT/MCC operators will forward written notice of intention to perform maintenance routines
involving deactivation of the LUT/MCC well in advance. The MCC will inform all other MCCs
as soon as a decision has been taken and confirm the times a minimum of two weeks prior to
deactivation.
LUT/MCC operator will inform the associated MCC by the quickest possible means, followed by
a written confirmation when an estimate of the duration of the downtime is available. The MCC
will immediately inform the other MCCs.
In the case of complete failure of the FMCC or in case of circumstances outside one’s control,
SPMCC will assume the duties of the FMCC. SPMCC will send validated Cospas-Sarsat alert

5-38

data, within the FMCC and/or other MCC service areas to designated SPOCs or RCCs. All
validated Cospas-Sarsat alert data within the Central DDR service area will be directly transmitted
to the Central DDR destination MCC.
As described in SPMCC section, FMCC should follow the procedure for backup termination when
is being backed up by SPMCC:
1.
FMCC requests backup through the MCC or phone;
2.
SPMCC implements the backup configuration and informs the rest of MCCs via SIT 605;
3.
FMCC informs SPMCC by phone when they are ready to go back in service, before
starting the distribution of messages;
4.
SPMCC removes the backup configuration and informs all MCCs (including FMCC) via
SIT 605; and
5.
FMCC starts transmitting alerts to SPMCC and other MCCs.
In the case that SPMCC has to assume the backup duties for FMCC, the Return Link Service (RLS)
shall not be interrupted and SPMCC shall become the associated MCC for the Galileo Return Link
Service Provider (RLSP) during the backup period.
In the case of a complete failure of SPMCC, FMCC will assume the duties of SPMCC. FMCC
will send validated Cospas-Sarsat alert data within the SPMCC service area and within other areas
to designated SPOCs or RCCs. In the Spanish SRR this will be RCC Madrid and CNCS (MRCC).
It was agreed to periodically exchange test messages between FMCC and the Spanish RCCs (RCC
Madrid and CNCS) to check the communication links. All validated Cospas-Sarsat alert data
within the South Central DDR service area will be directly transmitted to the South Central DDR
destination MCC.
Backup test between FMCC and SPMCC will be conducted on a “no noticed” basis as defined at
section 3-7 (contingency procedure) of this document.
In the case of complete failure of CMC, FMCC will assume the duties of CMC. FMCC will send
validated Cospas-Sarsat alert data within the CMC service area and within other areas to
designated SPOCs or RCCs. All validated Cospas-Sarsat alert data within the Eastern DDR service
area will be directly transmitted to the Eastern DDR destination MCCs.
In the case of complete failure of ITMCC, FMCC will assume the duties of ITMCC. FMCC will
send validated Cospas-Sarsat alert data within the ITMCC service area to designated SPOCs or
RCCs.
5.3.13.5 OTHER INFORMATION
A database of French registered beacons (named French 406 MHz Beacon Registration Database)
is maintained by FMCC. URL: https://registre406.cnes.fr.

5-39

Country codes supported by French registry:
COUNTRY CODE: COUNTRY NAME:
226, 227, 228
France

Guadeloupe (French Department of)

Martinique (French Department of)

St. Pierre and Miquelon

Adelie Land

New Caledonia

French Polynesia

Wallis and Futuna

Saint Paul and Amsterdam Island

Crozet Archipelago

Kerguelen Islands

La Réunion, Mayotte (French Department of)

Guiana (French Department of)

5-40

5.3.14 GRMCC - GREEK MISSION CONTROL CENTRE
Last updated: May 2024
5.3.14.1 GRMCC GENERAL
The Greek Mission Control Centre is located at the Hellenic Coast Guard Headquarters in Piraeus,
Greece. The LGM GRMCC controls a LEOLUT and a GEOLUT located at Penteli Mountain, as
well as a MEOLUT at the vicinity of Keratea area.
The LUTs are located at the following co-ordinates:
Latitude
Longitude
LEOLUT
38° 04.85′ N
023° 52.98′ E
GEOLUT
38° 04.85′ N
023° 52.95′ E
MEOLUT
37° 45.46′ N
024° 01.00′ E
The LEOLUT can localise transmitters and distress beacons in local mode and global mode.
LGM GRMCC and LUTs operate 24 hours a day throughout the year.
The communication interfaces used by LGM GRMCC are as follows:
•
FTP-VPN, AFTN, fax, voice.
5.3.14.2 SPOCs SUPPORTED
GRMCC provides primary support to the Greek JRCC and routes alert and notification (NOCR)
messages to other countries and can receive these messages from them.
5.3.14.3 SYSTEM INFORMATION MESSAGES
The following System information messages are received / originated at GRMCC:
•
Orbit vectors:
receive from FMCC,
•
SARP calibration:  receive from FMCC,
•
System status:
originate to and receive from FMCC,
•
Narrative:
receive and originate as required.
5.3.14.4 BACKUP PROCEDURES AND AGREEMENTS
The GRMCC operates two Operational Control Consoles (OCC), one of them being a backup. In
the event of GRMCC becomes unserviceable, Greece has backup agreements and procedures in
place with Italy. The following procedures have been agreed:
a)
The GRMCC notifies LGM ITMCC whenever the backup service is required by means
telephone and email. GRMCC notices ITMCC about the alert events which were handling
before the failure.

5-41

b)
The ITMCC notifies GRMCC when the backup service commences by fax, phone or email.
c)
The ITMCC sends a SIT 605 message notifying the other MCCs of the GRMCC failure, and
that ITMCC is performing backup service according to section 3.7 of document C/S A.001.
d)
The ITMCC transmits alerts for Greek service area in SIT 185 format to Greek JRCC using
the Greek JRCC AFTN link (primary communication link), email (secondary
communication link) or via fax (third communication link).
e)
In the event that the ITMCC is unable to communicate with the JRCC as described above,
the ITMCC shall; transmit alerts for the GRMCC service area in SIT 185 format to GRMCC
via AFTN link (primary communication link), email (secondary communication link( or via
fax (third communication link). In that case, the ITMCC will advise the GRMCC of their
inability to communicate with the Greek JRCC.
f)
The GRMCC advises the Greek JRCC about the GRMCC failure and about the backup
procedures.
g)
The GRMCC will notify the ITMCC as soon as the problem is solved and will advise the
time when the GRMCC plans to restore normal operations.
h)
When the GRMCC returns to normal operations it will send a SIT 605 message notifying
the ITMCC and other MCCs that the GRMCC has resumed normal operations. The GRMCC
also notifies the Greek JRCC that it has resumed normal operations.
i)
The ITMCC will notice to the GRMCC about the events handled during the backup.
j)
The ITMCC shall contact the GRMCC using the contact lists available at www.cospas-
sarsat.int.
k)
The ITMCC shall contact the JRCC Piraeus using the contact lists available at www.cospas-
sarsat.int.
l)
The GRMCC shall contact the ITMCC using the contact lists available at www.cospas-
sarsat.int.
5.3.14.5 OTHER INFORMATION
Beacon Registration
a)
A database of the Greek register for MMSIs (maritime beacons are coded only with MMSI)
is maintained by the Merchant Ships Inspectorate / Radio Communication Department of
Ministry of Shipping, Maritime Affairs and the Aegean, with a copy at GRMCC.
b)
A database of the Greek register for aviation Cospas-Sarsat beacons is maintained by the
Hellenic Ministry of Infrastructure and Transport / Civil Aviation Authority / Air Navigation
Services Regulatory Division / Telecommunication Services / Section (D4/D), with a copy
at GRMCC.
c)
A database of the Greek register for PLBs is accessible online via https://plb.hcg.gr
providing PLB registration information to the Piraeus Joint RCC and to the Fire Service.

5-42

5.3.15 HKMCC - HONG KONG MISSION CONTROL CENTRE
Last updated: June 2025
5.3.15.1 HKMCC GENERAL
The Hong Kong Mission Control Centre is located on Hong Kong Island in the MRCC controlling
one 6-channel MEOLUT and two advanced technology LEOSAR Local User Terminals (dual
LEOLUT system) located on the Peak on Hong Kong Island at the following location:
Latitude
Longitude
22° 16.56' N
114° 08.76' E
Both LEOLUTs can locate transmitters and distress beacons in local mode as well as global mode.
The local mode coverage of the Hong Kong LEOLUT covers the area from Mongolia in the north
to the south of Indonesia and from the eastern side of the Indian Ocean to the western part of the
Pacific.
HKMCC, MEOLUT and LEOLUTs operate 24 hours a day and provide alert data to countries
within the HKMCC service area in accordance with document C/S A.001 and national procedures.
A second operator control console (OCC) is available as a backup MCC and is located at the VTC
in Macau Ferry Terminal.
The Marine Department of Hong Kong is responsible for the operation of HKMCC and the
HKLEOLUT.
5.3.15.2 SPOCs SUPPORTED
•
Democratic People’s Republic of  orea,
•
Hong Kong, China,
•
Macau,
•
Philippines.
The communications interfaces used by the HKMCC are:
•
FTP-VPN, AFTN, fax, voice.
5.3.15.3 SYSTEM INFORMATION MESSAGES
The following System information is received / originated at HKMCC:
•
Orbit vectors:
receive from JAMCC,
•
SARP calibration: receive from JAMCC,
•
System status:
originate to and receive from JAMCC.

5-43

5.3.15.4 BACKUP PROCEDURE AND AGREEMENTS
HKMCC established a mutual backup procedure with TAMCC for system outage on either side.
In the case of complete failure of CNMCC, HKMCC will assume the duties of CNMCC.
In the case of complete failure of VNMCC, HKMCC will assume the duties of VNMCC.
The LUTs at Hong Kong, Singapore and Japan have overlapping local mode coverage areas to a
greater or lesser extent. It is therefore feasible for the Hong Kong area to be fully covered in the
case of failure or planned maintenance downtime.
5.3.15.5 OTHER INFORMATION
Beacon Registration
A register of beacons is maintained at HKMCC.

5-44

5.3.16 IDMCC - INDONESIA MISSION CONTROL CENTRE
Last updated: June 2025
5.3.16.1 IDMCC GENERAL
The Indonesia Mission Control Centre (IDMCC) and LEOLUT, and MEOLUT are respectively
located in the Basarnas Command Centre in Jakarta, and Jonggol, at the following location:
Latitude
Longitude
MCC (Jakarta)
06°09.42' S
106°39.36' E
LEOLUT (Jakarta)
06° 09.42' S
106° 50.46' E
MEOLUT (Jonggol, Java)
06° 29.53' S
107° 06' 32'' E
Jakarta LEOLUT (5254) can locate transmitters and distress beacons in local mode as well as
global mode.
The local mode coverage of the Indonesia LEOLUT is able to cover the area of Brunei, Malaysia,
Singapore, Papua New Guinea, Thailand (ASEAN Area) as well as Laos, Myanmar, South of
Philippines and North Australia.
IDMCC, MEOLUT and LEOLUT operate 24 hours a day (seven days a week) throughout the year.
The 6-channel MEOLUT was commissioned in 2020, and two additional channels were
commissioned in 2024.
The National SAR Agency of Indonesia (BASARNAS) is responsible for the operation of the
Jakarta LEOLUT, MEOLUT and MCC.
5.3.16.2 SPOCs SUPPORTED
IDMCC provides primary support to RCC Timor-Leste and forty-three Indonesian RSCs and
routes alert and notification (NOCR) messages to other countries and can receive these messages
from them.
The communications interfaces used by the IDMCC:
•
FTP-VPN, AFTN, fax, phone, HF radios on 13.525 MHz and 11.445 MHz.
5.3.16.3 SYSTEM INFORMATION MESSAGES
IDMCC originates and receives System information to/from AUMCC.
5.3.16.4 BACKUP PROCEDURES AND AGREEMENTS
The LUTs in Indonesia, Singapore and Australia have overlapping local mode coverage to greater
or less extent. It is therefore feasible for the Indonesia to be fully covered in the case of failure or
planned maintenance downtime.

5-45

In the event IDMCC becomes unserviceable, SIMCC will provide backup support to IDMCC. All
the alerts for the IDMCC service area will be transmitted in SITׄ 185 format to a fax number
nominated by IDMCC or via AFTN.
5.3.16.5 OTHER INFORMATION
Beacon Registration
IDMCC of the National SAR Agency of Indonesia (BASARNAS) maintains the database of all
registered 406 MHz beacons (ELTs, EPIRBs, PLBs).

5-46

5.3.17 INMCC - INDIAN MISSION CONTROL CENTRE
Last updated: May 2024
5.3.17.1 INMCC GENERAL
The Indian Mission Control Centre is located at Bengaluru and controls a national LEOLUT at the
following locations:
Latitude
Longitude
Lucknow (4192)
26° 54.80' N
080° 57.44' E
The LEOLUT can locate transmitters and distress beacons radiating in both local mode as well as
in global mode.
The coverage of the Indian LUT includes entire Indian sub-continent, adjacent sea regions, islands
and SPOCs mentioned below.
INMCC also controls one GEOLUT located at Bengaluru.
Latitude
Longitude
Bengaluru (4194)
13°02.09' N
077°30.70' E
INMCC and LUTs operate 24 hours a day throughout the year.
The Indian Space Research Organization (ISRO) of the Department of Space, Government of India
is responsible for the operation of the Indian MCC and LUTs.
5.3.17.2 SPOCs SUPPORTED
•
Bangladesh,
•
Bhutan,
•
Maldives,
•
Nepal,
•
Seychelles,
•
Sri Lanka,
•
Tanzania.
5.3.17.3 SYSTEM INFORMATION MESSAGES
The INMCC originates and receives the following System information:
•
Orbit vectors:
receive from CMC,
•
SARP calibration: receive from CMC,
•
System status:
originate to and receive from CMC.
5.3.17.4 COMMUNICATION INTERFACES
INMCC uses FTP-VPN to exchange data with MCCs as primary and AFTN as secondary. To send
Cospas-Sarsat distress alert to MRCCs, RCCs and SPOCs, INMCC uses AFTN link. Phone and
fax communications are also available with national and international SAR contacts.

5-47

5.3.17.5 BACKUP PROCEDURES
In the unlikely event of the INMCC failure, the INMCC has backup agreements with LGM CMC.
5.3.17.6 OTHER INFORMATION
Beacon Registration
INMCC maintains national beacon registration database of Indian beacons and provides alert and
registration information 24 hours per day throughout the year to National RCCs and MRCCs.
LGM Transition
MEOLUT: India is establishing a 7-antenna MEOLUT system at Bengaluru and has submitted the
commissioning report.
LGM MCC: India has already installed LGM MCC and is waiting for a time slot by CMC in order
to initiate commissioning by mid-2024.

5-48

5.3.18 ITMCC - ITALIAN MISSION CONTROL CENTRE
Last updated: May 2024
5.3.18.1 ITMCC GENERAL
The Italy Mission Control Centre is located in Bari, at the Coast Guard Naval Base.
One LEOLUT and one GEOLUT are co-located with LGM ITMCC.
LGM ITMCC controls the IT LEOLUT, GEOLUT, and the MEOSAR Network Location
Processor (IT NLP).
The IT LEOLUT can locate transmitters and distress beacons in local and global modes. Interferers
in the 406.0 MHz to 406.1 MHz frequency band are processed and forwarded to the ITU for
subsequent actions. The IT LEOLUT provides local mode coverage of Central Europe, the
Mediterranean Sea, Middle East Asia, and part of Central East Africa.
The IT GEOLUT tracks the geostationary satellites MSG-3 or MSG-4 as a backup.
The IT NLP is the system capable of receiving and processing MEOSAR alert data received from
multiple MEOLUTs, even if operated by a different Administration. The IT NLP is connected to
the EC MEOLUTs and the TR MEOLUT via FTP-VPN, Once the IT NLP is commissioned, it
will provide the IT LGM MCC with MEOSAR solutions.
LGM ITMCC is manned 24 hours per day throughout the year. A dedicated team manages and
monitors the IT LGM MCC and LUTs operations.
LGM ITMCC uses FTP-VPN and AFTN links to exchange data with other MCCs. AFTN, email
and fax are used  for communication with the ITMCC SPOCs. [...]
Phone communications are also available with national and international SAR contacts.
5.3.18.2 SPOCs SUPPORTED
The ITMCC provides alert and NOCR messages to the SPOCs of the following countries:
AFRICA:
•
Eritrea,
•
Ethiopia,
•
Kenya,
•
Somalia,
•
South Sudan,
•
Sudan.
MIDDLE EAST:
•
Israel,
•
Palestine.
EUROPE:
•
Albania,
•
Bosnia and
Herzegovina,
•
Croatia,
•
Italy,

5-49

•
Malta,
•
Montenegro,
•
North Macedonia,
•
San Marino,
•
Serbia,
•
Slovenia,
•
Vatican City.
5.3.18.3 SYSTEM INFORMATION MESSAGES
The following messages are received or originated at the Italian MCC:
•
System status:
originate and receive as required,
•
Narrative:
originates and receives as required,
•
Orbit vectors:
receives from FMCC,
•
SARP calibration: receives from FMCC.
5.3.18.4 BACKUP PROCEDURES AND AGREEMENTS
LGM ITMCC has a redundant solution to keep the MCC system running 24/7/365.
In the event of a complete LGM ITMCC failure, LGM FMCC will assume the backup of LGM
ITMCC.
LGM FMCC will distribute validated alert data within the LGM ITMCC service area to designated
SPOCs or RCCs.
LGM ITMCC provides backup facilities for LGM CYMCC, LGM GRMCC, and LGM TRMCC.
When ITMCC assumes the backup duties, a SIT 605 message is sent to all MCCs, notifying the
start of the backup. In addition, ITMCC informs the non-operational MCC SPOCs about the failure
of their associated MCC and the start of the backup.
When the backed-up MCC returns to normal operations, ITMCC sends a new SIT 605 to all MCCs,
notifying the end of the backup.
5.3.18.5 OTHER INFORMATION
Beacon Registration
ITMCC provides registration of 406 MHz beacons - EPIRBs, ELTs and PLBs (Country Code 247).
ITMCC maintains the national beacon registration database and provides the related information
24 hours per day throughout the year to SPOCs and RCCs.

5-50

5.3.19 JAMCC - JAPAN MISSION CONTROL CENTRE
Last updated: October 2023
5.3.19.1 JAMCC GENERAL
The Japan Mission Control Centre (JAMCC) is located at the Japan Coast Guard Headquarter in
Tokyo. It operates a LEOLUT (4311) and a MEOLUT (4314) both located in Futtsu.
Japan operates:
•
a LEOLUT (4311) which was installed in March 2020 in Futtsu and commissioned in
March 2021,
•
a MEOLUT(4314) with six antennas located in Futtsu which was commissioned in
December 2018 at EOC status with a declared coverage area (DCA) being a circle
centered at the MEOLUT site with a radius of 3,500 km and covering the Japanese search
and rescue region (SRR), i.e., over the Pacific Ocean from 17° N to the North and from
165° E to the West.
Futtsu LEOLUT and MEOLUT locations:
Latitude
Longitude
35° 14' 32.5’’ N
139° 55' 17.2’’ E
LGM JAMCC and LUTs operate 24 hours a day and send alert data to national RCCs within the
JAMCC service area in accordance with document C/S A.001 and national procedures.
LGM JAMCC also assumes the nodal responsibilities for the Northwest Pacific DDR as defined
at section 5.3 of this document.
The Japan Coast Guard (JCG) is responsible for the management and operation of the Japan
Cospas-Sarsat ground segment.
5.3.19.2 SPOCs SUPPORTED
LGM JAMCC provides primary support to the Japanese RCCs.
5.3.19.3 SYSTEM INFORMATION MESSAGES
The following System information is received / originated at JAMCC:
•
Orbit vectors:
receive from CNMCC, CMC, USMCC; and forward to CNMCC,
HKMCC, KOMCC, TAMCC and VNMCC, and to AUMCC, CMC,
FMCC, SPMCC, USMCC,
•
SARP calibration: receive from FMCC and forward to CNMCC, HKMCC, KOMCC,
TAMCC and VNMCC,
•
System status:
originate, receive and forward from / to AUMCC, CMC, FMCC,
USMCC, CNMCC, HKMCC, KOMCC, SPMCC, TAMCC and
VNMCC.

5-51

5.3.19.4 BACKUP PROCEDURE AND AGREEMENTS
In the event of a failure of the nodal JAMCC, the duty personnel will:
a)
contact and advise LGM USMCC to assume LGM JAMCC nodal responsibilities;
b)
contact and advise CNMCC, HKMCC, KOMCC, TAMCC and VNMCC to divert all their
traffic to LGM USMCC and to expect System information direct from LGM USMCC;
c)
request LGM USMCC to transmit LGM JAMCC service area alerts in SIT 185 format. LGM
JAMCC will attempt to pass them to its service area RCCs/SPOCs by manually geosorting
them; and
d)
advise  LGM USMCC that LGM JAMCC will pass alerts from Japanese LUTs in some form
on a ‘best effort’ basis.
5.3.19.5 OTHER INFORMATION
Beacon Registration
JAMCC maintains access to an external national beacon register.

5-52

5.3.20 KOMCC - KOREA MISSION CONTROL CENTRE
Last updated: June 2025
5.3.20.1 KOMCC GENERAL
The Korea Mission Control Centre is located at the Korea Coast Guard Headquarters (KCG) in
Incheon . It controls one LEOLUT and a MEOLUT installed at the following locations:
Latitude
Longitude
Incheon LEOLUT
37° 23.58' N
126° 38.94' E
Geumsan MEOLUT
36° 07.50' N
127° 29.35' E
The local mode of the Korea LEOLUT covers the area from the eastern part of Russia in the north
to the Philippines and from the eastern part of China in the west to the western part of Pacific
Ocean.
The LEOLUT can locate transmitters and distress beacons in local mode as well as global mode.
The Korea MCC and LEOLUT operate 24 hours a day throughout the year and send alert data to
countries within the KOMCC service area in accordance with document C/S A.001 and national
procedures.
The 6-channel Geumsan MEOLUT was commissioned in 2020.
The KOMCC has been LGM-capable since February 2024.
The Korea Coast Guard is responsible for the operation of KOMCC and LUT.
5.3.20.2 SPOCs SUPPORTED
KOMCC provides alert data to Korean RCCs.
5.3.20.3 SYSTEM INFORMATION MESSAGES
The following System information is received / originated at KOMCC:
•
Orbit vectors:
received from JAMCC,
•
SARP calibration: received from JAMCC,
•
System status:
originated to and received from JAMCC.
5.3.20.4 BACKUP PROCEDURES AND AGREEMENTS
In the case of complete failure of KOMCC, LGM JAMCC will assume the duties of KOMCC.
The communication interfaces used by the KOMCC are:
•
FTP-VPN, AFTN, fax, voice.

5-53

5.3.20.5 OTHER INFORMATION
Beacon Registration
A database of beacon registration is maintained by National Radio Management Service and
Central Radio Management. KOMCC can refer to the Database using links with those two
organizations.

5-54

5.3.21 MYMCC – MALAYSIA MISSION CONTROL CENTER
(Section under development)
Last updated: February 2018
5.3.21.1 MYMCC GENERAL
The Malaysia Mission Control Centre is at the following address and location:
Malaysian Maritime Enforcement Agency / Maritime Academy Sultan Ahmad Shah / Prime
Minister Department, Sg. Ular, Gebeng, 26100 Kuantan, Malaysia.
Latitude
Longitude
TBD
TBD
5.3.21.2 SPOCs SUPPORTED
Malaysia.
5.3.21.3 SYSTEM INFORMATION MESSAGES
To be determined.
5.3.21.4 BACKUP PROCEDURE AND AGREEMENTS
To be determined.
5.3.21.5 OTHER INFORMATION
A database of registered beacons is maintained by the Malaysia Maritime Enforcement Agency -
MMEA.

5-55

5.3.22 NIMCC - NIGERIA MISSION CONTROL CENTRE
Last updated: February 2018
5.3.22.1 NIMCC GENERAL
Since 2016, the NIMCC has been out-of-service and configured as a SPMCC SPOC.

5-56

5.3.23 NMCC - NORWEGIAN MISSION CONTROL CENTRE
Last updated: May 2024
5.3.23.1 NMCC GENERAL
The Norwegian Ground Segment equipment consists of the LEOLUT in Spitsbergen and LGM
MCC in Bodo. The Norwegian Mission Control Center (NMCC) is also connected to the
EU/Spitsbergen MEOLUT. These form the NMCC with the Spitsbergen LEOLUT and the
MEOLUT at Svalbard as the technical bodies of the MCC, and LGM NMCC Bodo as the
operational body. NMCC is integrated and co-located with JRCC Bodo.
The LUTs are installed at the following locations:
Latitude
Longitude
Spitsbergen LEOLUT
78° 13.74' N
015° 23.76' E
EU/Spitsbergen MEOLUT
78° 13.74' N
015° 23.76' E
LGM NMCC also provides global mode locations. LGM NMCC operates 24 hours per day, seven
(7) days a week.
5.3.23.2 SPOCs SUPPORTED
LGM NMCC provides alert data to SPOCs in the NMCC service area including:
•
Denmark
•
Estonia
•
Faroe Islands
•
Finland
•
Greenland
•
Iceland
•
Latvia
•
Lithuania
•
Norway
•
Poland
•
Sweden
A summary of communication systems for these interfaces follows:
•
SPOCs in NMCC service area:
FTP, AMHS, fax, voice
•
LGM CYMCC:
FTP-VPN, AMHS, fax, voice,
•
LGM FMCC:
FTP-VPN, AMHS, fax, voice,
•
LGM ITMCC:
FTP-VPN, AMHS, fax, voice,
•
LGM UKMCC:
FTP-VPN, AMHS, fax, voice,
•
LGM TRMCC:
FTP-VPN, AMHS, fax, voice,
•
LGM GRMCC:
FTP-VPN, AMHS, fax, voice,
•
LGM SPMCC (nodal backup):
FTP-VPN, AMHS, fax, voice.
5.3.23.3 SYSTEM INFORMATION MESSAGES
NMCC originates and receives the following System information messages:
•
System status:
originate and receive, normally through FMCC,
•
Narrative:
for status messages,
•
SARP calibration: via FMCC,
•
Orbit vectors:
via FMCC.

5-57

5.3.23.4 BACKUP PROCEDURES AND AGREEMENTS
The Spitsbergen LEOLUT has overlapping local mode coverage areas to a greater or lesser extent
with the following LEOLUTs: Lee-On-Solent (UK) and Toulouse (France). It is therefore feasible
for one to back up the other in the case of failure or planned maintenance downtime.
In the case of complete failure of LGM NMCC, LGM UKMCC will assume the duties of LGM
NMCC. LGM UKMCC will send validated Cospas-Sarsat alert data, within the LGM NMCC
service area to designated SPOCs or RCCs.
In the case of complete failure of UKMCC, NMCC will assume the duties of LGM UKMCC.
LGM NMCC will send validated Cospas-Sarsat alert data, within the UKMCC service area to
designated SPOCs or RCCs. In the UK SRRs this will be MRCC Falmouth.
5.3.23.5 OTHER INFORMATION
NMCC has access 24/7 to the Norwegian beacon registries (EPIRBs, ELTs and PLBs with country
codes 257, 258 and 259).
The Ministry of Justice and Public Security is responsible for the administrative coordination of
the Norwegian Rescue Service (http://www.regjeringen.no/en/dep/jd.html?id=463).
NMCC is collocated with JRCC North-Norway.

5-58

5.3.24 PAMCC - PAKISTAN MISSION CONTROL CENTRE
Last updated: October 2023
5.3.24.1 PAMCC GENERAL
The Pakistan Mission Control Centre is located at the Space Research Centre (SPARCENT),
SUPARCO Karachi and controls one Local User Terminal (LUT) and two Rescue Coordination
Centres (RCCs) at Karachi:
Latitude
Longitude
24° 56.76' N
067° 08.16' E
The PALUT can locate distress beacons in local mode, as well as in global mode. In addition, the
PALUT can process the repeater channel for interference monitoring.
The local mode-coverage of the PALUT includes countries from Saudi Arabia to China and the
Commonwealth of Independent States (CIS) to Sri Lanka.
The PALUT and PAMCC are operating 24 hours a day throughout the year. The Pakistan Space
and Upper Atmospheric Research Commission (SUPARCO) is responsible for the PALUT and
PAMCC operations while RCC1 is operated by Pakistan Civil Aviation Authority (CAA) and
RCC2 is operated by Pakistan Maritime Security Agency (MSA).
5.3.24.2 SPOCs SUPPORTED
•
Pakistan.
5.3.24.3 SYSTEM INFORMATION MESSAGES
PAMCC receives and originates System status information from/to LGM CMC.
5.3.24.4 BACKUP PROCEDURES AND AGREEMENTS
In the unlikely event of PAMCC failure, PAMCC has backup agreements with LGM CMC.
5.3.24.5 OTHER INFORMATION
A register of national units equipped with beacons will be maintained in the IBRD and locally at
PAMCC.

5-59

5.3.25 PEMCC - PERUVIAN MISSION CONTROL CENTRE
Last updated: October 2023
5.3.25.1 PEMCC GENERAL
The Peruvian Mission Control Centre is located in Callao. PEMCC controls one LEOLUT and one
GEOLUT located at the following co-ordinates:
Latitude
Longitude
LEOLUT
12° 01.84′ S
077° 07.79′
GEOLUT
12° 01.85′ S
077° 07.80′
The local mode coverage of the Peruvian LEOLUT covers the areas of Bolivia, Colombia, Costa
Rica, Ecuador, French Guiana, Guatemala, Guyana, Panama, Paraguay, Surinam, Uruguay,
Venezuela, and parts of Argentina, Brazil, and Chile, and extends 3,000 nm into the Pacific Ocean
to the West.
PEMCC and LUTs operate 24 hours a day, seven (7) days per week.
The communication interfaces used by the PEMCC are:
•
Peruvian RCCs:
voice, email,
•
LUTs to PEMCC:
FTP ,
•
USMCC:
FTP-VPN, AFTN, voice, email,
•
AUMCC (as part of USMCC backup):
FTP-VPN, AFTN, voice, email.
The General Direction of Captaincies and Coast Guard of the Peruvian Navy (DICAPI) is
responsible for the Peruvian LEOLUT, GEOLUT, MCC and Peruvian RCCs operations.
5.3.25.2 SPOCs SUPPORTED
PEMCC has no SPOCs in its service area. However, PEMCC provides primary support to the
Peruvian RCCs.
5.3.25.3 SYSTEM INFORMATION MESSAGES
The following System information is received / originated at PEMCC:
•
Orbit vectors:
received via USMCC,
•
SARP calibration:
received via USMCC,
•
System status:
received and originated as required,
•
Narrative:
received and originated as required.
5.3.25.4 BACKUP PROCEDURES AND AGREEMENTS
In the unlikely event of a PEMCC failure, Peru has a backup agreement with Brazil since 2024. In
accordance with the following procedures, BRMCC will assume the duties of PEMCC:

5-60

a)
PEMCC notifies BRMCC by phone or optionally by email when the backup service is
required.
b)
BRMCC notifies PEMCC when backup service commences by phone, fax or email.
c)
BRMCC sends a SIT 605 message notifying all MCCs of PEMCC failure and that the
BRMCC is performing backup service according to section 3.7 of document C/S A.001.
d)
BRMCC transmits alerts for the Peruvian service area in SIT 185 format to PEMCC via fax
or email;
e)
Once the failure is overcome, PEMCC sends a SIT 605 message notifying BRMCC and all
MCCs that PEMCC has resumed normal operations.
f)
BRMCC will send all requested missing messages to PEMCC.
5.3.25.5 OTHER INFORMATION
406 MHz EPIRBs / ELTs have been approved for carriage on Peruvian vessels / aircraft.
PEMCC is responsible for the assignment of serial numbers for all serialized coded beacons and
the maintenance of the Peruvian 406 MHz beacon registration database. PEMCC can be contacted
at any time to obtain beacon registration information. Likewise, PEMCC registers all the data of
the Peruvian beacons in the IBRD of Cospas-Sarsat.

5-61

5.3.26 QAMCC - QATAR MISSION CONTROL CENTRE
Last updated: June 2025
5.3.26.1 QAMCC GENERAL
The Qatar Mission Control Centre is relocated  to the new position at Al Daayen, Zone 70, State
of Qatar. QAMCC (4660) controls a LEOLUT (4661) and a GEOLUT (4662) located at the
previous position of QAMCC.
After relocation, the new position of QAMCC is 25° 33.08’ N, 051° 26.82’ E.
The LUTs are located at the following co-ordinates:
Latitude
Longitude
LEOLUT (4661)
25° 30.00′ N
051° 27.24′ E
GEOLUT (4662)
25°29.94′ N
051° 27.25′ E
QAMCC and LUTs operate 24 hours a day throughout the year.
The second GEOLUT (4663) is installed and under commissioning. A MEOLUT is ordered for
installation and commissioning in 2026.
Ministry of Defence through Doha Joint Rescue Coordination Centre (DJRCC) is responsible for
management and operation of the Qatar Cospas–Sarsat ground segment.
5.3.26.2 SPOCs SUPPORTED
QAMCC provides primary support to DJRCC and routes alert and notification (NOCR) messages
to other countries and can receive these messages from them.
The communication interfaces used by QAMCC are as follows:
•
FTP-VPN, AMHS, fax, email and voice.
5.3.26.3 SYSTEM INFORMATION MESSAGES
The following System information messages are received / originated at QAMCC:
•
Orbit vectors:
receive from SPMCC,
•
SARP calibration:  receive from SPMCC,
•
System status:
originate to and receive from SPMCC,
•
Narrative:
receive and originate as required.
5.3.26.4 BACKUP PROCEDURES AND AGREEMENTS
In case of complete failure of QAMCC, SPMCC will assume the duties of QAMCC. SPMCC will
send validated Cospas-Sarsat alert data within QAMCC service area to DJRCC.

5-62

As described in respective SPMCC section, QAMCC should follow the procedure for backup
termination when is being backed up by SPMCC:
1. QAMCC requests backup through the MCC or phone;
2. SPMCC implements the backup configuration and informs the rest of MCCs via SIT 605;
3. QAMCC informs SPMCC by phone when they are ready to go back in service, before
starting the distribution of messages;
4. SPMCC removes the backup configuration and informs all MCCs (including QAMCC)
via SIT 605; and
5. QAMCC starts transmitting alerts to SPMCC.
As described in respective SPMCC section, in the case of a complete failure of SPMCC, FMCC
will assume the duties of SPMCC. In that case, QAMCC will change its configuration in order to
consider FMCC as its current nodal MCC until the backup situation is finished. When the backup
is finished, QAMCC will revert to its normal configuration in order to consider SPMCC as its
nodal MCC.
5.3.26.5 OTHER INFORMATION
Beacon Registration
All Qatar coded EPIRBs, ELTs and PLBs operating on 406 MHz shall have to be registered on the
International Beacon Registration Database (IBRD) or on the national database for the special
government beacons.

5-63

5.3.27 SAMCC - SAUDI ARABIAN MISSION CONTROL CENTRE
Last updated: June 2025
5.3.27.1 SAMCC GENERAL
The Saudi Arabian Mission Control Centre (SAMCC) is co-located with the RCC in Jeddah.
SAMCC is currently commissioned as LGM.
SAMCC controls two LEOLUTs with G-SARP. These two LUTs are located at:
Latitude
Longitude
21 39.29' N
039 08.56' E
These two LEOLUTs are known as SALUT1 (ID: 4031) and SALUT2 (ID: 4032) and provide
local mode coverage of the whole Middle East region.
SAMCC and LEOLUTs operate 24 hours a day throughout the year providing alert data through
the co-located RCC.
SAMCC also operates a six-channel MEOLUT (4034) commissioned in 2019 which is located in
Jeddah at the following location:
Latitude
Longitude
21 39.29' N
039 08.56' E
Additionally, the installation of four extra MEOLUT channels in Riyadh has been completed and
the commissioning report is planned to be submitted to the Cospas-Sarsat Secretariat when it is
ready.
The Saudi General Authority of Civil Aviation (GACA) is responsible for the management and
operation of the Saudi Cospas-Sarsat ground segment.
5.3.27.2 SPOCs SUPPORTED
•
Bahrain,
•
Jordan,
•
Kuwait,
•
Lebanon,
•
Oman,
•
Saudi Arabia,
•
Syria,
•
Yemen.
The communication interfaces used by SAMCC are FTP-VPN and AFTN.
5.3.27.3 SYSTEM INFORMATION MESSAGES
SAMCC originates and receives the following System information messages:
•
Orbit vectors:
receive from SPMCC,
•
SARP calibration: receive from SPMCC,
•
System status:
originate and receive from SPMCC.

5-64

5.3.27.4 BACKUP PROCEDURES AND AGREEMENTS
In the case of complete failure of SAMCC, LGM SPMCC will assume the duties of SAMCC.
LGM SPMCC will send validated Cospas-Sarsat alert data within SAMCC service area to
designated SPOCs.
As described in SPMCC section, SAMCC should follow the procedure for backup termination
when is being backed up by SPMCC:
1.
SAMCC requests backup through the MCC or phone;
2.
SPMCC implements the backup configuration and informs the rest of MCCs via SIT 605
message;
3.
SAMCC informs SPMCC by phone when they are ready to go back in service, before
starting the distribution of messages;
4.
SPMCC removes the backup configuration and informs all MCCs (including SAMCC)
via SIT 605 message; and
5.
SAMCC starts transmitting alerts to SPMCC.
In a backup situation, it is not guaranteed that messages sent to the Saudi Arabia primary AFTN
address are received by the SAMCC/Jeddah RCC staff, for that reason a secondary AFTN address
has been implemented to provide message service to the Jeddah RCC during backup.
Therefore, in case of any situation that SPMCC has to backup SAMCC, SPMCC will send alerts
within the Saudi Arabia MCC service area to the Jeddah RCC using the secondary AFTN address,
which was provided for that purpose. In case the AFTN link is unavailable, SPMCC will use the
fax. In the event that the Jeddah RCC is evacuated for any reason, a backup ARCC site, located in
the Saudi Air Navigation Services (SANS) headquarters building, will be activated using the same
communications links as the primary site. Confirmation of RCC activation will be coordinated
between the two parties. Contact details for the backup ARCC are available on the Cospas-Sarsat
contact details webpage.
Operators will forward a written notice to their backup MCC of intention to perform maintenance
routines requiring a backup at least 24 hours in advance.
As described in SPMCC section, in the case of a complete failure of SPMCC, FMCC will assume
the duties of SPMCC. In that case, SAMCC will change its configuration in order to consider
FMCC as its current nodal MCC until the backup situation is finished. When the backup is finished,
SAMCC will revert to its normal configuration in order to consider SPMCC as its nodal MCC.
5.3.27.5 OTHER INFORMATION
A national database for EPIRBs, ELTs and PLBs is maintained by SAMCC.
SAMCC has prepared a specific template to be used in case there is a justified need for a 406 MHz
beacon live / operational activation for more details please contact SAMCC at email:
samcc.sar@sans.com.sa.

5-65

5.3.28 SIMCC - SINGAPORE MISSION CONTROL CENTRE
Last updated: May 2024
5.3.28.1 SIMCC GENERAL
The Singapore Mission Control Centre (SIMCC) is located at the Singapore Air Traffic Control
Centre (SATCC), LORADS Complex, Biggin Hill at the following location:
Latitude
Longitude
01° 23.40' N
103° 59.10' E
LGM SIMCC controls a 6-antenna MEOLUT and a LEOLUT located near Changi Airport.
LGM SIMCC operates 24 hours a day throughout the year.
The LUTs operate in global mode and provide local mode coverage of Singapore, Brunei,
Indonesia, Malaysia, South West of Philippines, Cambodia, Laos, Myanmar and North West of
Australia.
The Civil Aviation Authority of Singapore (CAAS) and the Maritime and Port Authority of
Singapore (MPA) are responsible for the operation of SIMCC.
5.3.28.2 SPOCs SUPPORTED
LGM SIMCC provides alert data to the Singapore Rescue Coordination Center (SIRCC) and the
Search and Rescue Points of Contact (SPOCs) in the SIMCC service area including:
•
Brunei,
•
Myanmar,
•
Malaysia.
The communication interfaces used by SIMCC are:
•
AUMCC:
FTP-VPN, AFTN, voice,
•
SIRCC:
FTP-VPN, fax, voice,
•
SPOCs:
AFTN, fax, voice.
5.3.28.3 SYSTEM INFORMATION MESSAGES
SIMCC originates and receives the following System information messages:
•
Orbit vectors:
receive from AUMCC,
•
SARP calibration:  receive from AUMCC,
•
System status:
originate and receive from AUMCC,
•
Narrative:
originate and receive from AUMCC.

5-66

5.3.28.4 BACKUP PROCEDURES AND AGREEMENTS
The LEOLUTs in Singapore,  Indonesia and Thailand have overlapping local mode coverage areas
to a greater or lesser extent. It is therefore feasible for one to backup another in the case of failure
or planned maintenance downtime.
In the event the LGM SIMCC becomes unserviceable, THMCC will provide backup support to
the SIMCC. All the alerts for SIMCC service area will be transmitted in SIT 185 format to a fax
number nominated by SIMCC or via AFTN.
LGM SIMCC provides backup for THMCC and IDMCC. Should THMCC or IDMCC require a
backup, messages will be sent to them via AFTN or fax.
5.3.28.5 OTHER INFORMATION
Beacon Registration
A register of national ships equipped with beacons is maintained by the Maritime and Port
Authority of Singapore (MPA). Users of maritime EPIRBs installed on Singapore registered ships
are required to register their EPIRBs with the MPA and the Info-communications Media
Development Authority (IMDA) Licensing Department.
A register of all Emergency Locator Transmitters (ELTs) is maintained by CAAS. Users of ELTs
carried on board Singapore registered aircraft are required to register their beacons with CAAS.
A register for both EPIRBs and ELTs is maintained at SIMCC.

5-67

5.3.29 SPMCC - SPANISH MISSION CONTROL CENTRE
Last updated: October 2023
5.3.29.1 SPMCC GENERAL
The Spanish Mission Control Centre is co-located with its LUTs in Instituto Nacional de Técnica
Aeroespacial (INTA) at the Maspalomas Tracking Station in Gran Canaria, at the following
location:
Latitude
Longitude
27°45.68' N
015°37.90' W
The LEOLUT is equipped with a dedicated antenna which makes possible tracking of all Cospas-
Sarsat satellites passing over Canary Islands, unless satellites are in conflict.
The LEOLUT can localise transmitters and distress beacons in local mode and global mode.
Interferers in the 406.0 MHz to 406.1 MHz band are localised in the local mode, and this
information is provided to the Spanish Telecommunication Administration for action through ITU.
The Maspalomas LEOLUT provides local mode coverage of North-Central Atlantic and North
West Africa to latitude 0 degrees and operates 24 hours per day throughout the year.
SPMCC also controls two GEOLUTs which are co-located with the LEOLUT.
SPMCC is directly connected to the MEOLUT/EC located in Maspalomas INTA Station and to
the other MEOLUT/EC in Norway and Cyprus.
Alert data are validated and transmitted to MCCs and SPOCs, in accordance with document
C/S A.001 and national procedures.
SPMCC also assumes the nodal responsibilities for the South Central DDR as defined at section
5.3 of this document.
5.3.29.2 SPOCs SUPPORTED
SPMCC receives alert data from the Maspalomas LEOLUT and GEOLUTs and from other
Cospas-Sarsat MCCs in accordance with document C/S A.001. It provides Cospas-Sarsat alert data
to the following countries:
•
Benin
•
Cameroon
•
Cape Verde
•
Central
African
Republic
•
Congo
•
Côte d'Ivoire
•
Equatorial Guinea
•
Gabon
•
Gambia
•
Ghana
•
Guinea
•
Guinea-Bissau
•
Liberia
•
Mali
•
Mauritania
•
Nigeria
•
Sao
Tome
and
Principe
•
Senegal
•
Sierra Leone
•
Spain
•
Togo

5-68

The communication interfaces used by SPMCC are:
•
AEMCC:
FTP-VPN, AFTN,
•
ALMCC:
FTP-VPN, AFTN,
•
AUMCC:
FTP-VPN, AFTN,
•
CMC:
FTP-VPN, AFTN,
•
FMCC:
FTP-VPN, AFTN,
•
JAMCC:
FTP-VPN, AFTN,
•
QAMCC
FTP-VPN, AFTN,
•
SAMCC:
FTP-VPN, AFTN,
•
USMCC:
FTP-VPN, AFTN.
5.3.29.3 SYSTEM INFORMATION MESSAGES
The following System information is received / originated at SPMCC:
•
Orbit vectors:
receive from CMC, USMCC and JAMCC, and forward to AEMCC,
ALMCC, QAMCC and SAMCC,
•
SARP calibration: receive from FMCC and forward to AEMCC, ALMCC, QAMCC
and SAMCC,
•
System status:
originate, receive from and forward to AEMCC, ALMCC, AUMCC,
CMC, FMCC, JAMCC, NIMCC, QAMCC, SAMCC and USMCC.
5.3.29.4 BACKUP PROCEDURE AND AGREEMENTS
The Maspalomas LEOLUT has overlapping local mode coverage areas with the following
LEOLUTs: Bari, Lee-On-Solent, Maspalomas, Ouargla and Toulouse. It is feasible for one to
backup the other in case of failure or planned maintenance downtime. Co-operation in the coverage
of individual satellite passes may also be feasible in the future.
The LUT operators will forward written advance notice of routine maintenance deactivation of a
LUT. The MCC will advise all others MCCs as soon as decision has been taken and confirm the
times a minimum of two weeks before deactivation. In case of failure, the LUT operators will
inform the associated MCC in the quickest possible way followed by a written confirmation when
an estimate of the duration of the downtime is available. The MCC will inform immediately the
MCCs in South Central DDR and the nodal MCCs.
SPMCC: In the case of a complete failure of LGM SPMCC, LGM FMCC will assume the duties
of the SPMCC. FMCC will send validated Cospas-Sarsat alert data within the SPMCC service
area and within other areas to designated SPOCs or RCCs. In the Spanish SRR this will be RCC
Madrid and CNCS (MRCC). It was agreed to periodically exchange test messages between FMCC
and the Spanish RCCs (RCC Madrid and CNCS) to check the communication links. All validated
Cospas-Sarsat alert data within the South Central DDR service area will be directly transmitted to
the destination MCC.

5-69

FMCC: In the case that SPMCC has to assume the backup duties for FMCC, SPMCC will be able
to process and relay the alert messages originally created for FMCC, that is to say, with MF \#5 set
to 2270.
In the case that SPMCC has to assume the backup duties for LGM FMCC, the Return Link Service
(RLS) shall not be interrupted and LGM SPMCC shall become the associated MCC for the Galileo
Return Link Service Provider (RLSP) during the backup period.
AEMCC: In the case of complete failure of AEMCC, LGM SPMCC will assume the duties of
AEMCC. SPMCC will send validated Cospas-Sarsat alert data within AEMCC service area to Abu
Dhabi SAR Coordination Center for further distribution to AEMCC designated SPOCs.
ALMCC: In the case of a complete failure of LGM ALMCC, LGM SPMCC will assume the
duties of ALMCC. SPMCC will send validated Cospas-Sarsat alert data within ALMCC service
area to designated SPOCs. In the Algerian SRR this will be Algiers RCC (this AFTN address is
DAALZSZX).
QAMCC: In case of complete failure of LGM QAMCC, LGM SPMCC will assume the duties of
QAMCC. SPMCC will send validated Cospas-Sarsat alert data within QAMCC service area to
designated SPOCs. Operators will forward a written notice to their backup MCC of intention to
perform maintenance routines requiring a backup at least 24 hours in advance.
SAMCC: In the case of a complete failure of SAMCC, LGM SPMCC will assume the duties of
SAMCC. LGM SPMCC will send validated Cospas-Sarsat alert data within SAMCC service area
to designated SPOCs.
The LGM SPMCC has the capability to re-route messages to another MCC. However, although
this capability is available, there is no agreement with any other MCC to use this message re-
routing.
The procedure for backup termination when an MCC is being backed up by LGM SPMCC would
be as follows, where XXMCC could be any MCC with backup agreements with LGM SPMCC:
1.
XXMCC requests backup through the MCC or phone,
2.
SPMCC implements the backup configuration and informs the rest of MCCs via SIT 605,
3.
XXMCC informs SPMCC by phone when they are ready to go back in service, before
starting the distribution of messages,
4.
SPMCC removes the backup configuration and informs all MCCs (including XXMCC)
via SIT 605,
5.
XXMCC starts transmitting alerts to SPMCC.
5.3.29.5 OTHER INFORMATION
Beacon Registration

5-70

A database of the Spanish register for maritime Cospas-Sarsat beacons is maintained by the
General Directorate of Merchant Navy, and another database of the Spanish register for aviation
Cospas-Sarsat beacons is maintained by the General Directorate of Civil Aviation, with a copy of
both databases at SPMCC.

5-71

5.3.30 TAMCC - ITDC / TAIPEI MISSION CONTROL CENTRE
Last updated: June 2025
5.3.30.1 TAMCC GENERAL
The ITDC / Taipei Mission Control Centre is located in the building of Maritime and Port Bureau
(MPB), MOTC. in Taipei city. It operates one MEOLUT (4163) and two LEOLUTs (4164 and
4165), all located in Dapinding, Pingtung County, Chinese Taipei, with the following co-ordinates:
Latitude
Longitude
22° 01.26’ N
120° 41.58’ E
The MEOLUT is an eight-antenna installation. Six antennas are dedicated to the MEOLUT. Two
additional antennas (considered as LEOLUTs) are LEO/MEO antennas that track LEOSAR
satellites as a priority and MEOSAR satellites whenever no LEOSAR satellite is visible to the site.
Both LEOLUTs can localise transmitters and distress beacons in local mode and global mode.
TAMCC, its MEOLUT and LEOLUTs operate 24 hours a day throughout the year.
The TAMCC has been LGM-capable since March 2022.
The Maritime and Port Bureau (MPB) of the Ministry of Transport and Communications are
responsible for the management and operation of TAMCC and its associated MEOLUT and
LEOLUTs.
5.3.30.2 SPOCs SUPPORTED
TAMCC provides primary support to Chinese Taipei RCCs.
The communication interfaces used by TAMCC are:
•
FTP-VPN, AMHS, voice, fax.
5.3.30.3 SYSTEM INFORMATION MESSAGES
TAMCC originates and receives the following System information messages:
•
Orbit vectors:
receive from JAMCC,
•
SARP calibration: receive from JAMCC,
•
System status:
originate to and receive from JAMCC.
5.3.30.4 BACKUP PROCEDURES AND AGREEMENTS
TAMCC established a mutual backup procedure with HKMCC for system outage on either side.
ITDC LEOLUTs have overlapping local mode coverage areas to a greater or lesser extent with the
following LEOLUTs: Guam, Hong Kong, Jakarta, Nakhodka, Singapore, Incheon and Futtsu. It is

5-72

therefore feasible for the Chinese Taipei area to be fully covered in the case of failure or planned
maintenance downtime.
5.3.30.5 OTHER INFORMATION
Beacon Registration
PLB and EPIRB registration is maintained by Maritime and Port Bureau (MPB), MOTC. ELT
registration is maintained by Civil Aeronautics Administration (CAA).
In order to speed up the registration process, MPB has established an official registration website
since March 2022. The user can register their beacon information on the website and sync it to
IBRD after successful registration.

5-73

5.3.31 TGMCC - TOGO MISSION CONTROL CENTRE
(Section under development)
Last updated: June 2025
5.3.31.1 TGMCC GENERAL
The Togo Mission Control Centre is located in a building within the army headquarters in Lomé.
It operates one MEOLUT Next and RCC Next located in the same building with the following
MEOLUT “Next” antenna co-ordinates:
Latitude
Longitude
6.207454 N
1.233206 W
The MEOLUT Next system is constituted of several RF chains (one for each GNSS constellation).
These RF chains provide one data first level (TOA/FOA files) from signal servers to data server
across the local loop network. One RF chain is composed of the 64 L-band antennas patches, 4 RF
Dispatch Unit (RF-ADU) of 16 inputs each, to interface with one RF block, one splitter (to allow
swapping of equipment in case of failure) and one digitizer.
TGMCC, its MEOLUT “Next” and RCC “Next” operate 24/7.
A commission of the Togolese presidency placed under the supervision of the ministry of public
works and infrastructure is responsible for the management and operation of TGMCC and its
associated MEOLUT and RCC.
5.3.31.2   SPOCs SUPPORTED
In its initial operational configuration, TGMCC will support the RSC in Togo.
The communication interfaces used by TGMCC are FTP-VPN, AMHS, voice and fax.
5.3.31.3 SYSTEM INFORMATION MESSAGES
TGMCC will receive and process the following System information messages:
•
Orbit Vectors,
•
SARP Calibration Data,
•
SARR Calibration data,
•
System Status,
•
Narrative.
TGMCC is capable of originating the following system information messages:
•
System Status,
•
Narrative.
These messages will normally be received from, or sent to, the designated nodal MCC (SPMCC).

5-74

5.3.31.4 BACKUP PROCEDURE AND AGREEMENTS
In the event TGMCC becomes unserviceable, a local spare server is available. The switch to spare
TGMCC server will be transparent for any nodal MCC and local RCC.
In the event SPMCC becomes unserviceable, FMCC will switch as TGMCC nodal and will
provide backup support to TGMCC. All alerts for TGMCC service area will be transmitted in SIT
185 format and to a fax number nominated by TGMCC or via AMHS. TGMCC will ensure
distribution to the supported RCCs/SPOCs.
5.3.31.5 OTHER INFORMATION
In 2025, TGMCC is installed and ready for the commissioning.

5-75

5.3.32 THMCC - THAILAND MISSION CONTROL CENTRE
Last updated: May 2024
5.3.32.1 THMCC GENERAL
The Thailand Mission Control Centre (THMCC) is located at the Department of Airports in
Bangkok. THMCC controls two LEOLUTs. [...]
The Thai LEOLUTs provide full capability processing, including G-SARP processing of the
transponded SARR data and combined LEO/GEO processing, according to the relevant Cospas-
Sarsat specifications. The local coverage area of the Thai LEOLUTs includes the Bay of Bengal,
parts of the Indian Ocean, and the South China Sea, as well as the land area of South Asia,
including all of Thailand and the Malaysian Peninsula.
The entire Thai Ground Segment is designed for 24 hours, seven days a week, operations.
5.3.32.2 SPOCs SUPPORTED
In its initial operational configuration, THMCC will support the RCCs in Thailand.
5.3.32.3 SYSTEM INFORMATION MESSAGES
THMCC will receive and process the following System information messages:
•
Orbit Vectors
•
SARP Calibration Data
•
SARR Calibration data
•
System Status
•
Narrative
THMCC is capable of originating the following system information messages:
•
System Status
•
Narrative
These messages will normally be received from, or sent to, the designated nodal MCC.
5.3.32.4 BACKUP PROCEDURES AND AGREEMENTS
In the event THMCC becomes unserviceable, LGM SIMCC will provide backup support to
THMCC. All alerts for THMCC service area will be transmitted in SIT 185 format and to a fax
number nominated by THMCC or via AFTN. THMCC will ensure distribution to the RCCs and
SPOCs it supports.
The local coverage area of the Thai LEOLUTs overlaps with the coverage area of LEOLUTs
operated by Hong Kong (China), India, Indonesia, Singapore, and ITDC. In the fringe coverage
areas, there is also some overlap with LUTs operated by China (P. R. of), Japan, Korea, Pakistan,
and the USA (Guam).

5-76

5.3.32.5 OTHER INFORMATION
In 2024, THMCC is in the process of installing a new MEOLUT and a new LGM MCC.

5-77

5.3.33 TRMCC - TÜRKIYE MISSION CONTROL CENTRE
Last updated: October 2023
5.3.33.1 TRMCC GENERAL
The Türkiye Mission Control Centre is located at the Main SAR Coordination Centre (MSRCC)
building (G.M.K. Bulvari No: 128/A, 06570 Maltepe, Ankara). LGM TRMCC has been operating
at LGM IOC level since 17 December 2020 and at LGM FOC level since 21 June 2021 (MEOSAR
EOC standard). Two LEOLUTs and one GEOLUT and one 6-channel MEOLUT are installed at
the Ankara Esenboga Airport.
LUTs are located at the following co-ordinates:
Latitude
Longitude
LEOLUT (1)
40° 08.45' N
032° 59.38' E
LEOLUT (2)
40° 08.44' N
032° 59.38' E
GEOLUT
40° 08.42' N
032° 59.40' E
MEOLUT
40° 08.48' N
032° 59.39' E
Türkiye LEOLUTs can localise transmitters and distress beacons in local mode and global mode.
TRMCC and LEOLUTs operate 24 hours a day throughout the year.
The communication interfaces used by TRMCC are as follows:
•
AFTN, FTP-VPN, fax, voice.
5.3.33.2 SPOCs SUPPORTED
TRMCC provides primary support to the Türkiye RCCs and routes alert and notification (NOCR)
messages to other countries and can receive these messages from them. TRMCC distributes alert
data for the following SPOCs: Afghanistan, Georgia\*, Iran, Iraq, and Ukraine\*.
Note: * There is an overlap with the CMC service area.
5.3.33.3 SYSTEM INFORMATION MESSAGES
TRMCC originates and receives the following System information messages:
•
Orbit vectors:
receive from FMCC,
•
SARP calibration: receive from FMCC,
•
System status:
originate to and receive from FMCC,
•
Narrative:
received and originated as required.

5-78

5.3.33.4 BACKUP PROCEDURES AND AGREEMENTS
LGM TRMCC operates two Operational Control Consoles (OCC), one of them being a backup.
In the event of failure of TRMCC, Türkiye has backup agreements and procedures in place with
Italy. The following procedures have been agreed to:
a)
Whenever the backup service is required, TRMCC notifies LGM ITMCC by means of fax,
phone or email;
b)
ITMCC notifies TRMCC when the backup service commences by fax, phone or email;
c)
ITMCC sends a SIT 605 message notifying the other MCCs of the TRMCC failure, and that
ITMCC is performing backup service according to section 3.7, document C/S A.001;
d)
TRMCC advises the Turkish RCCs and SPOCs about the TRMCC failure and the backup
procedures;
e)
ITMCC transmits alerts for the Turkish service area in SIT 185 format to:
•
TRMCC using the Turkish MSRCC fax, and
•
TRMCC SPOCs using SPOCs communication links mentioned in item (l) below;
f)
In the event that ITMCC is unable to communicate with TRMCC and/or TRMCC SPOCs as
described above, ITMCC shall transmit alerts for the Turkish service area in SIT 185 format
to MSRCC/Ankara via Inmarsat-C Telex or fax. In this case, ITMCC will advise
MSRCC/Ankara of their inability to communicate with TRMCC and/or the TRMCC SPOCs.
Other Turkish RCCs and SPOCs as well as TRMCC will be advised by MSRCC/Ankara;
g)
TRMCC will notify ITMCC as soon as the problem is solved, and will advise the time when
TRMCC plans to restore normal operations;
h)
When TRMCC returns to normal operations it will send a SIT 605 message notifying
ITMCC and other MCCs that TRMCC has resumed normal operations. TRMCC will also
notify its RCCs and SPOCs that it has resumed normal operations;
i)
ITMCC will send all requested missing messages to TRMCC;
j)
ITMCC shall contact TRMCC using the contact lists available at www.cospas-sarsat.int;
k)
ITMCC shall contact MSRCC/Ankara using the contact lists available at www.cospas-
sarsat.int;
l)
ITMCC shall contact the TRMCC SPOCs using the contact lists available at www.cospas-
sarsat.int for:
•
Iran (Tehran RCC),
•
Iraq & Afghanistan (Qatar JPRC),
•
Georgia,
•
Ukraine;
m)
TRMCC shall contact ITMCC using the contact lists available at www.cospas-sarsat.int.
5.3.33.5 OTHER INFORMATION
TRMCC has 24/7 access to the Turkish Beacon Registries (for EPIRBs, ELTs and PLBs).

5-79

The Ministry of Transportation and Infrastructure is responsible for the administrative
coordination of the Turkish SAR Service. TRMCC is co-located with MSRCC Ankara, Türkiye.

5-80

5.3.34 UKMCC - UNITED KINGDOM MISSION CONTROL CENTRE
Last updated: May 2024
5.3.34.1 UKMCC GENERAL
The United Kingdom Mission Control Centre is located at Fareham, Hampshire, England and
controls one 6-antenna MEOLUT, one hybrid MEOLUT/LEOLUT and one GEOLUT, located at
Lee-On-Solent, Hampshire, in SW England. The UKMCC has a Disaster Recovery backup system
contained within a separate server.
LGM UKMCC is manned 24 hours per day throughout the year, including public holidays.
UKMCC contact details can be obtained using the contact lists available at www.cospas-sarsat.int.
The UK LEOLUT operates in the global mode and provides local mode coverage of Europe, the
Eastern half of the North Atlantic Ocean and part of Southern Scandinavia. Alert data from the
UK LEOLUT/MEOLUT, the GEOLUT and the 6-channel MEOLUT is transmitted to UKMCC
via Kilostream lines.
UKMCC uses AFTN, FTP-VPN, fax, point-to-point datalink and voice phone to distribute data to
MCCs and RCCs.
5.3.34.2 SPOCs SUPPORTED
MCC provides alert data to the  nited  ingdom’s MRCCs and Police Forces, and to the
Republic of Ireland’s MRCC Dublin. UKMCC also provides alert and Notification of Beacon
Registration (NOCR) messages to MCCs within the Central Data Distribution Region. Alert
messages for areas outside the Central DDR are routed to FMCC. NOCR messages are routed in
accordance with Table 4-1 of document C/S A.001.
The communications interfaces used by UKMCC are:
•
UK MRCCs:
fax, voice, email
•
Irish MRCC:
FTP, fax, voice,
•
UK Police:
fax, email (see note), voice.
Note:  All distress-alert transmissions to SPOCs, over whichever data medium, are accompanied
by a telephone call.
5.3.34.3 SYSTEM INFORMATION MESSAGES
The following System information messages are received / originated at UKMCC:
•
Orbit vectors:
received from FMCC,
•
SARP calibration:
received from FMCC,
•
System status:
received and originated as required,
•
Narrative:
received and originated as required,
•
406 MHz SARR frequency calibration:
receive from CMCC.

5-81

5.3.34.4 BACKUP PROCEDURES AND AGREEMENTS
The UK LEOLUT/MEOLUT has overlapping local mode coverage areas to a greater or lesser
extent with the following LEOLUTs: Bari, Maspalomas, Ouargla, Spitsbergen and Toulouse. It is
therefore feasible for one to back up the other in the case of failure or planned maintenance
downtime.
LEOLUT operators will forward a written notice of intention to perform maintenance routines
involving deactivation of LEOLUT well in advance. The MCC will inform all other MCCs as soon
as a decision has been taken and confirm the times a minimum of two weeks prior to deactivation.
The LEOLUT operator will inform the associated MCC by the quickest possible means, followed
by a written confirmation when an estimate of the duration of the downtime is available. The MCC
will immediately inform the other MCCs.
UKMCC has a backup facility, but, in the case of complete failure of UKMCC, NMCC will assume
the duties of UKMCC. NMCC will send validated Cospas-Sarsat alert data within UKMCC service
area to designated SPOCs or RCCs. In the UK SRRs this will be the Joint Rescue Coordination
Centre, Fareham, and for Eire, this will be MRCC Dublin.
UKMCC provides backup facilities for NMCC.
5.3.34.5 OTHER INFORMATION
A register of UK EPIRBs, ELTs and PLBs is maintained at MRCC Falmouth.

5-82

5.3.35 USMCC - UNITED STATES MISSION CONTROL CENTRE
Last updated: June 2025
5.3.35.1 USMCC GENERAL
The United States Mission Control Centre is located at the National Oceanic and Atmospheric
Administration’s Satellite Operations Facility in Suitland, Maryland.
LGM USMCC controls multiple operational LEOLUTs at the following locations: Fairbanks,
Alaska (2 LEOLUTs), Wahiawa, Hawaii Andersen AFB (2 LEOLUTs, 2 LEO/MEOLUTs), Guam
(2 LEOLUTs), and Miami, Florida (2 LEOLUTs, 2 LEO/MEOLUTs). The new LEO/MEOLUT
antennas at both the Hawaii and Florida sites are scheduled to track a LEOSAR satellite when a
LEOSAR satellite is available; otherwise, they track a MEOSAR satellite as part of the associated
MEOLUT in Hawaii or Florida, respectively.
LGM USMCC controls two full time operational GEOLUTs (MD1 and MD2) co-located with
USMCC in Suitland, Maryland. A third GEOLUT, the GEOSAR Support Equipment (GSE) also
located in Suitland, is used for GEOLUT system development and testing but can also be used
operationally when needed.
LGM USMCC also controls two operational MEOLUTs with six dedicated antennas each, located
in Wahiawa, Hawaii and Miami Florida. These MEOLUTs normally operate in networked mode.
As described above, LEOSAR/MEOSAR antennas are used as part of the MEOLUT in Florida or
Hawaii when no LEOSAR satellites is available, enabling the Hawaii and the Florida MEOLUTs
to track up 8 and 9 satellites, respectively.
USMCC also controls a LEOLUT co-located with USMCC in Suitland, Maryland known as the
LEOSAR/MEOSAR Support Equipment (LME). The LME is used for LEOLUT system
development and testing. When not being used for development and testing, the LME is used
operationally. The LME antenna is capable of tracking either a LEOSAR or a MEOSAR satellite
and tracks a MEOSAR satellite as part of the Florida MEOLUT when no LEOSAR satellite is
available.
The LEOLUTs provide coverage of the U.S. SRR from the mid-Atlantic to the western-Pacific,
and from the North Pole to approximately 15 degrees south.
LGM USMCC uses a dedicated Private Internet Protocol (PIP) network for communications with
its LUTs and the majority of its RCCs. AFTN and FTP-VPN are used for communication with
other MCCs. AFTN, FTP-VPN and fax are used for communication with USMCC SPOCs.
LGM USMCC also performs the nodal responsibilities for the Western DDR as defined at section
5.3 of this document.
The National Oceanic and Atmospheric Administration is the lead agency in the United States for
the Cospas-Sarsat Programme.
5.3.35.2 SPOCs SUPPORTED
In support of the United States National Search and Rescue Plan, LGM USMCC provides alert
and NOCR messages to U.S. Coast Guard and Air Force Rescue Co-ordination Centres. LGM
USMCC distributes alert and NOCR messages to the following SPOCs:

5-83

CARIBBEAN:
•
Bahamas 1
•
Barbados 3
•
Belize 2
•
British Virgin Islands 3
•
Cayman Islands 1
•
Costa Rica 2
•
Cuba 1
•
Curacao
•
Dominican Republic
•
El Salvador 2
•
Grenada 3
•
Guatemala 2
•
Haiti
•
Honduras 2
•
Jamaica 1
•
Mexico
•
Nicaragua 2
•
Panama
•
St. Vincent and the
Grenadines 3
•
Trinidad and Tobago
•
Turks
and
Caicos
Island 1
•
US Virgin Islands 3
Notes:
(1)
Alert messages for this SPOC are distributed to the USCG District 7 RCC.
(2)
Alert messages for this SPOC are distributed to COCESNA (Corporación Centroamericana de
Servicios de Navegación Aérea or Central American Corporation for Air Navigation Services).
(3)
Alert messages for this SPOC are distributed to USCG Sector San Juan RCC.
SOUTH AMERICA:
•
Colombia
•
Guyana
•
Ecuador
•
Venezuela
ATLANTIC:
Bermuda
PACIFIC:
•
Marshall Islands 1
•
Micronesia 2
•
Northern Mariana
Islands 2
•
Palau 2
Notes:
(1)
Alert messages for all this SPOC are distributed to USCG District 14.
(2)
Alert messages for these SPOCs are distributed to USCG Sector Guam.
5.3.35.3 SYSTEM INFORMATION MESSAGES
USMCC processes the following System information messages:
•
SARR command verification and SARR Telemetry: originates to CMCC;
•
SARP command verification and SARP Telemetry: originates to FMCC;
•
SARR command: receives from CMCC;
•
SARP command: receives from FMCC;
•
System status: originates, receives and sends;
•
Narrative: originates, receives and sends;
•
Orbit vectors: originates, receives, validates and sends;
•
SARP calibration: receives, validates and sends;
•
406 MHz SARR frequency calibration: receives, validates and sends.

5-84

5.3.35.4 BACKUP PROCEDURES AND AGREEMENTS
In the unlikely event of a complete LGM USMCC failure, the USA has backup agreements and
procedures in place with Australia (LGM) and Canada (LG) as described below. USMCC
maintains an in-house system with redundant hardware in order to keep USMCC running 24/7/365.
The USA also maintains a backup USMCC at the NOAA Consolidated Backup Facility in
Fairmont, West Virginia. Backup procedures will be used during the period of time required to
transition from USMCC in Suitland, Maryland to the backup USMCC in Fairmont or if USMCC
in Suitland and the backup USMCC in Fairmont experience a simultaneous outage such as may
occur during a regional power outage.
SMCC also maintains a remote operation facility in NOAA’s Center for  eather and Climate
Prediction building in College Park, Maryland. USMCC Controller can monitor and control the
MCC from the remote facility in circumstances where personal are evacuated from the Suitland
facility, but USMCC is operational. The controllers can also access the backup USMCC at
Fairmont from the remote facility.
Australia provides backup for our nodal MCC responsibility and Canada provides backup for the
USA RCC and SPOCs. USMCC has provided Canada with Geosort data for USA RCCs and
SPOCs.
In the event of a USMCC outage that lasts or is expected to last more than one (1) hour, LGM
AUMCC will be requested to assume nodal responsibilities for the Western DDR and send alerts
for the USA service area to CMCC, and LG CMCC will be requested to support USMCC by
sending alert data directly to the USA RCCs and SPOCs.
USMCC also has agreements to provide backup when needed for CMCC (Canada), BRMCC
(Brazil) and the CHMCC (Chile).
5.3.35.5 OTHER INFORMATION
406 MHz EPIRBs / ELTs have been approved for carriage on U.S. vessels and aircraft and PLBs
are authorized for personal use in the USA. A beacon register for USA beacons is maintained at
USMCC.

5-85

5.3.36 VNMCC – VIET NAM MISSION CONTROL CENTRE
Last updated: November 2022
5.3.36.1 VNMCC GENERAL
The Viet Nam Mission Control Centre is located at the Viet Nam Maritime Communication and
Electronics Company in Haiphong. The VNMCC controls one LEOLUT.
The Viet Nam LEOLUT provides full processing, including G-SARP processing of the
‘transponded’ SARR data, according to the relevant Cospas-Sarsat specifications. The local
coverage area of the Viet Nam LEOLUT includes the Bay of Bengal, parts of the Indian Ocean,
and the South China Sea, as well as the land area of South Asia, including all of Viet Nam.
The entire Viet Nam ground segment is designed for 24 hours, seven days a week, operations.
5.3.36.2 SPOCs SUPPORTED:
•
Cambodia,
•
Lao P. D. R,
•
Viet Nam,
The communication interfaces used by the VNMCC are:
•
FTP-VPN, AFTN, fax, voice.
5.3.36.3 SYSTEM INFORMATION MESSAGES
VNMCC receives and processes the following System information messages:
•
Orbit vectors:
receive from JAMCC,
•
SARP calibration data:
receive from JAMCC,
•
System status:
originating to and receive from JAMCC.
The VNMCC is capable of originating the following System information messages:
•
System Status,
•
Narrative.
These messages are normally received from or sent to JAMCC.
5.3.36.4 BACKUP PROCEDURES AND AGREEMENTS
In the event VNMCC can not provide its service, VNMCC emails and makes a phone call to
request HKMCC providing backup to VNMCC. HKMCC and VNMCC perform the backup
procedure according to section 3.7 document C/S A.001. HKMCC distributes all alert messages
in SIT 185 format on behalf of VNMCC to designated Viet Nam RCCs, Cambodia SPOCs and
Lao P. D. R SPOCs via AFTN.
The local coverage area of the Viet Nam LEOLUT overlaps with the LEOLUTs operated by Hong
Kong, India, Indonesia, ITDC, Singapore, and Thailand. In the fringe coverage areas, there is also
some overlap with LUTs operated by China, Japan, Korea, Pakistan, and the United States (Guam).

5-86

5.3.36.5 OTHER INFORMATION
None.
- END OF SECTION 5 -
- END OF DOCUMENT -

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