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

title	description	sidebar	documentId	series	seriesName	documentType	isLatest	issue	revision	documentDate	originalTitle
A001: C/S A.001 Issue 8 - Rev.11	Official Cospas-Sarsat A-series document A001	badge text variant A note	A001	A	Operational	operational	true	8	11	October 2025	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

---

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

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

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

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

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

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

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

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

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]

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

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

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

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

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

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

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: 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: SUBJECT: MANOEUVRE OF SATELLITE STATUS OF MANOEUVRE: <SCHEDULED, EXECUTED OR CANCELLED> TYPE OF MANOEUVRE: <IN PLANE, OUT OF PLANE OR BOTH> SAR INSTRUMENTS ACTIVE DURING MANOEUVRE: MANOEUVRE START TIME:

UTC MANOEUVRE END TIME:

UTC [REPEAT INFORMATION ABOUT MANOEUVRE START AND END TIME AS NEEDED] TIME NEW ORBIT VECTORS ARE EXPECTED:

UTC MAXIMUM EXPECTED CHANGE IN SATELLITE POSITION DUE TO THE SATELLITE MANOEUVRE: KM AFTER HOURS MAXIMUM EXPECTED ERROR IN DOPPLER LOCATION: KM AFTER HOURS THIS DOPPLER LOCATION ERROR INCLUDES A NOMINAL SYSTEM ERROR OF 5 KM. COMMENTS - MCCS SHOULD 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: 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