--- title: "G010: C/S G.010 Issue 1 - Rev.3" description: "Official Cospas-Sarsat G-series document G010" sidebar: badge: text: "G" variant: "note" # Extended Cospas-Sarsat metadata documentId: "G010" series: "G" seriesName: "General" documentType: "overview" isLatest: true issue: 1 revision: 3 documentDate: "October 2024" originalTitle: "C/S G.010 Issue 1 - Rev.3" --- > **📋 Document Information** > > **Series:** G-Series (General) > **Version:** Issue 1 - Revision 3 > **Date:** October 2024 > **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents) --- MCC HANDBOOK C/S G.010 Issue 1 – Revision 3 ![Image 1 from page 1](/images/cospas-sarsat/G-series/G010/G010_page_1_img_1.png) MCC HANDBOOK HISTORY Issue Revision Date Comments Approved by CSC-64 Approved by CSC-66 Approved by CSC-69 Approved by CSC-71 TABLE OF CONTENTS Page History.............................................................................................................................................. i Table of Contents ............................................................................................................................ ii List of Annexes .............................................................................................................................. v List of Figures ................................................................................................................................. x List of Tables .................................................................................................................................. x 1. INTRODUCTION ....................................................................................................... 1-1 1.1 Purpose ....................................................................................................................... 1-1 1.2 Scope ........................................................................................................................... 1-2 1.3 Document Organization ............................................................................................ 1-2 2. THE COSPAS-SARSAT PROGRAMME ................................................................ 2-1 2.1 General ....................................................................................................................... 2-1 2.2 History ........................................................................................................................ 2-1 2.2.1 Stakeholder Organizations ................................................................................. 2-4 2.3 Cospas-Sarsat Website .............................................................................................. 2-9 2.4 Cospas-Sarsat Reference Documents .................................................................... 2-11 2.4.1 General Reference Documents ........................................................................ 2-11 2.4.2 Programme Documents .................................................................................... 2-12 2.4.3 Operational Documents ................................................................................... 2-13 2.4.4 Technical Documents....................................................................................... 2-13 2.4.5 IBRD Documents ............................................................................................. 2-14 2.4.6 Cospas-Sarsat Videos....................................................................................... 2-14 3. OVERVIEW OF THE COSPAS-SARSAT SYSTEM ............................................. 3-1 3.1 Mission Statement ..................................................................................................... 3-1 3.2 Introduction ............................................................................................................... 3-1 3.3 Beacon Segment ......................................................................................................... 3-2 3.4 Space Segment ........................................................................................................... 3-5 3.5 Ground Segment ........................................................................................................ 3-8 4. THE MISSION CONTROL CENTRE ...................................................................... 4-1 4.1 Overview..................................................................................................................... 4-1 4.1.1 Functions of an MCC ......................................................................................... 4-1 4.1.2 Operational Requirements ................................................................................. 4-2 4.1.3 Location and Facilities ....................................................................................... 4-4 4.1.4 Management and Personnel ............................................................................... 4-4 4.1.5 MCC Equipment ................................................................................................ 4-5 4.1.6 Automatic Operations ........................................................................................ 4-7 4.2 Processing LUT Data ................................................................................................ 4-9 4.3 Cospas-Sarsat Data Distribution Plan ..................................................................... 4-9 4.3.1 MCC Service Area ............................................................................................. 4-9 4.3.2 DDRs and Nodal MCCs................................................................................... 4-10 4.3.3 RCCs, SPOCs and Search and Rescue Regions .............................................. 4-12 4.3.4 Alert Data Distribution .................................................................................... 4-15 4.3.5 System Data Distribution ................................................................................. 4-19 4.4 Data Communication .............................................................................................. 4-22 4.4.1 Communication Links ...................................................................................... 4-24 4.4.2 Interfaces .......................................................................................................... 4-26 4.5 SIT Messages............................................................................................................ 4-29 4.5.1 Introduction ...................................................................................................... 4-29 4.5.2 MCC to MCC Incident Alert Messages ........................................................... 4-30 4.5.3 MCC to RCC/SPOC Messages ........................................................................ 4-30 4.5.4 System Information .......................................................................................... 4-30 4.5.5 Narrative Messages .......................................................................................... 4-30 4.6 Quality Management System ................................................................................. 4-30 4.6.1 QMS Evaluation............................................................................................... 4-31 4.6.2 MCC Roles in QMS ......................................................................................... 4-32 5. MCC OPERATIONS .................................................................................................. 5-1 5.1 Management............................................................................................................... 5-1 5.1.1 Staffing ............................................................................................................... 5-2 5.1.2 Training .............................................................................................................. 5-2 5.1.3 Voice Communications ...................................................................................... 5-3 5.1.4 Language ............................................................................................................ 5-3 5.2 Daily Operations ........................................................................................................ 5-4 5.2.1 Activities for MCC System Manager ................................................................ 5-5 5.2.2 Activities for MCC Operator ............................................................................. 5-7 5.2.3 Monitoring the Operation of MCC .................................................................... 5-8 5.2.4 Test Procedures .................................................................................................. 5-9 5.2.5 MCC Operational Backup................................................................................ 5-11 5.3 Monitoring and Test Activities ............................................................................... 5-12 5.3.1 MCC Commissioning ...................................................................................... 5-12 5.3.2 Monitoring the National Ground Segment ...................................................... 5-16 5.3.3 Communications Link Monitoring .................................................................. 5-17 5.3.4 Space Segment Monitoring .............................................................................. 5-22 6. FUNCTIONS OF AN MCC OPERATOR ................................................................ 6-1 6.1 Communications with SPOCs .................................................................................. 6-1 6.2 Communications with other MCCs ......................................................................... 6-3 6.2.1 General Communications................................................................................... 6-3 6.2.2 Narrative Messages ............................................................................................ 6-4 6.2.3 System Status Messages .................................................................................... 6-5 6.2.4 SIT Messages Embedded in Narrative Messages .............................................. 6-5 6.3 Monitoring the System .............................................................................................. 6-6 6.3.1 External Systems Monitoring ............................................................................ 6-6 6.3.2 Reference Beacon Monitoring ........................................................................... 6-7 6.4 MCC Backups ............................................................................................................ 6-7 6.5 Communications Support ......................................................................................... 6-8 6.6 Resending a Missing Message ................................................................................ 6-10 6.7 Suppressing Beacon Alerts ..................................................................................... 6-12 6.8 Quality Management System Messages ................................................................ 6-15 6.9 Beacon Registration Requests ................................................................................ 6-17 6.10 System Data Updates............................................................................................... 6-21 6.10.1 LEOSAR Orbital Elements .............................................................................. 6-22 6.10.2 MEOSAR Orbital Elements ............................................................................. 6-23 6.10.3 GEOSAR Orbital Elements ............................................................................. 6-24 6.10.4 LEOSAR SARP Calibration ............................................................................ 6-24 6.10.5 LEOSAR SARR Calibration............................................................................ 6-25 6.10.6 MEOSAR SARR Calibration .......................................................................... 6-26 6.10.7 GEOSAR SARR Calibration ........................................................................... 6-27 6.11 Satellite Manoeuvres ............................................................................................... 6-27 6.12 Satellite Outages ...................................................................................................... 6-30 6.13 Coverage Analysis ................................................................................................... 6-31 6.13.1 LEOSAR Coverage .......................................................................................... 6-31 6.13.2 MEOSAR Coverage......................................................................................... 6-32 6.13.3 GEOSAR Coverage ......................................................................................... 6-32 6.14 Beacon Testing ......................................................................................................... 6-32 6.14.1 Beacon Self-Test Messages ............................................................................. 6-33 6.14.2 Test Beacons and Beacon Simulators .............................................................. 6-33 6.14.3 Notification of a Planned Beacon Test ............................................................ 6-34 6.14.4 Processing Data from a Beacon Test ............................................................... 6-36 6.14.5 System-Wide Tests .......................................................................................... 6-36 ANNEXES ANNEX A : DATA DISTRIBUTION ..................................................................................... A-1 A.1 Nodal Data Distribution Network ........................................................................... A-1 A.1.1 Special Rules ..................................................................................................... A-2 A.1.2 Cospas-Sarsat GEOSORT ................................................................................ A-2 A.1.2.1 Data Distribution Regions ............................................................................ A-2 A.1.3 MCC Service Areas .......................................................................................... A-3 A.1.4 Message Formatting .......................................................................................... A-3 A.1.5 Alert Message Validation ................................................................................. A-3 A.2 Alert Data Distribution ............................................................................................ A-4 A.3 DDP Processing Matrices ........................................................................................ A-4 A.4 Alert Types ................................................................................................................ A-8 A.4.1 Unlocated Alerts ............................................................................................... A-8 A.4.2 Alerts with Beacon Position Estimates ............................................................. A-8 A.4.2.1 Position Data ................................................................................................ A-9 A.4.3 Confirmed Beacon Alerts ................................................................................. A-9 A.4.3.1 Matching and Merging of Beacons ............................................................ A-10 A.4.3.2 Beacon Confirmation ................................................................................. A-10 A.4.3.3 Position Confirmation ................................................................................ A-10 A.4.3.4 Distribution of Confirmed Solutions .......................................................... A-10 A.4.3.5 Conflict Solutions ....................................................................................... A-11 A.4.4 Alert Message Contents .................................................................................. A-11 A.4.5 Alert Message Routing ................................................................................... A-12 A.4.6 Continued Transmission ................................................................................. A-13 A.4.7 Special Processing .......................................................................................... A-13 A.4.7.1 Ship Security Alert ..................................................................................... A-14 A.4.7.2 Return Link Service Alert .......................................................................... A-14 A.4.7.3 Distress Tracking ELT Alert ...................................................................... A-16 A.4.7.4 System Beacons ......................................................................................... A-18 A.4.7.5 Notification of Country of Registration Alert ............................................ A-21 A.4.7.6 Cancellation Message ................................................................................. A-22 A.5 Message Transmission ........................................................................................... A-23 A.6 Data Validation ....................................................................................................... A-23 A.6.1 406 MHz Alert Message Validation ............................................................... A-23 A.6.2 Concept of Filtering Redundant Data and Better-Quality Alerts .................... A-26 A.6.3 Event Flags...................................................................................................... A-26 A.6.4 Distance Criteria ............................................................................................. A-27 A.6.5 Image Position Determination ........................................................................ A-29 A.6.6 Satellite Footprint Verification ....................................................................... A-29 A.6.7 Bit Errors ......................................................................................................... A-29 A.6.7.1 Satellite Link Errors ................................................................................... A-30 A.6.7.2 LUT to MCC Errors ................................................................................... A-30 A.6.7.3 MCC to MCC Errors .................................................................................. A-31 A.6.7.4 MCC to RCC Errors ................................................................................... A-31 A.6.7.5 MCC Bit Error Processing ......................................................................... A-31 A.7 System Data Distribution ....................................................................................... A-31 A.7.1 System Data SIT Message Formats ................................................................ A-32 A.7.2 Satellite Orbit Messages ................................................................................. A-33 A.7.2.1 Position and Velocity Vectors .................................................................... A-33 A.7.2.2 NORAD Two-Line Elements ..................................................................... A-34 A.7.2.3 Orbit Reference Coordinate System ........................................................... A-34 A.7.3 System Calibration .......................................................................................... A-34 A.7.3.1 SARP Calibration ....................................................................................... A-34 A.7.3.2 SARR Calibration ...................................................................................... A-35 A.7.4 Spacecraft Instrument Control Messages........................................................ A-35 A.7.5 System Status and Narrative Messages........................................................... A-35 A.7.5.1 System Status ............................................................................................. A-36 A.7.5.2 Narrative Messages .................................................................................... A-36 A.7.6 Beacon Registration Data ............................................................................... A-36 ANNEX B : DESCRIPTION OF SIT MESSAGES ............................................................... B-1 B.1 International Character Set .................................................................................... B-1 B.2 Message Subject Indicator Types ........................................................................... B-2 B.3 Message Fields .......................................................................................................... B-4 B.3.1 Message Field Identification ............................................................................. B-5 B.3.2 Message Field Descriptions .............................................................................. B-5 B.4 Lists of Message Fields ............................................................................................. B-6 B.4.1 Control Fields.................................................................................................... B-6 B.4.2 Beacon Identification and Beacon Message ..................................................... B-8 B.4.3 Solution Data .................................................................................................... B-8 B.4.3.1 Spacecraft Identification ................................................................................. B-10 B.4.3.2 Orbit Number .................................................................................................. B-11 B.4.3.3 Source Identifier.............................................................................................. B-11 B.4.3.4 Frequency Band .............................................................................................. B-11 B.4.3.5 Solution Frequency ......................................................................................... B-11 B.4.3.6 Time ................................................................................................................ B-12 B.4.3.7 Number of Points or Bursts............................................................................. B-12 B.4.4 Solution Quality Data ..................................................................................... B-12 B.4.5 Message Fields for SIT 185 Messages............................................................ B-13 B.5 Incident Alert Messages ......................................................................................... B-13 B.5.1 Unlocated Alerts ............................................................................................. B-14 B.5.2 Encoded Location Alert .................................................................................. B-14 B.5.3 Independent Location Alert ............................................................................ B-14 B.5.3.1 Doppler Location Alert ................................................................................... B-15 B.5.3.2 Difference of Arrival Location Alert .............................................................. B-16 B.5.4 Special Message Formats ................................................................................ B-16 B.5.5 Unconfirmed Location Alert ........................................................................... B-17 B.5.6 Confirmed Location Alert ............................................................................... B-17 B.5.7 Conflict Solution Alert .................................................................................... B-17 B.5.8 Notification of Country of Registry ................................................................ B-18 B.5.9 Ship Security Alerting System Alert............................................................... B-18 B.5.10 Aircraft Distress Tracking Alert ..................................................................... B-18 B.5.11 Return Link System Notification .................................................................... B-18 B.5.12 Interferer Alerts ............................................................................................... B-18 B.5.12.1 Number of Sidebands ................................................................................. B-19 B.5.12.2 Sweep Period and Standard Deviation ....................................................... B-19 B.6 System Information ................................................................................................ B-19 B.6.1 Orbital Elements ............................................................................................. B-19 B.6.1.1 SIT 215 Message Format (Orbit Vectors) ...................................................... B-20 B.6.1.2 SIT 216 Message Format (Orbit Vectors) ...................................................... B-20 B.6.1.3 SIT 217 Message Format (Two-Line Elements) ............................................ B-20 B.6.2 LEOSAR SARP Calibration ........................................................................... B-21 B.6.3 LEOSAR SARR Calibration........................................................................... B-21 B.6.4 Satellite Command and Control Messages ..................................................... B-22 B.6.5 System Status .................................................................................................. B-23 B.6.5.1 SIT 605............................................................................................................ B-23 B.7 Narrative Messages ................................................................................................ B-24 B.7.1 Narrative Message Text .................................................................................. B-24 B.7.2 SIT 915 (Simple Narrative Message) ............................................................. B-24 B.7.3 SIT 925 (406 MHz Beacon Information with 15-Hex ID) ............................. B-25 B.7.4 SIT 926 (406 MHz Beacon Information with 23-Hex ID) ............................. B-25 B.7.5 SIT 927 (SGB Type Approval Information for MCCs) ................................. B-25 B.7.6 SIT 985 (SGB Type Approval Information for SPOCs and RCCs) ............... B-25 B.8 Operational Message Templates ........................................................................... B-26 B.8.1 SIT 605 – MCC Backup ................................................................................. B-26 B.8.2 SIT 605 – MCC Resuming Operations after the Backup ............................... B-29 B.8.3 SIT 915 – Beacon Test Coordination.............................................................. B-30 B.8.4 SIT 915 – Cospas-Sarsat Alert Results ........................................................... B-31 B.8.5 Filtering Doppler Position............................................................................... B-34 B.9 QMS Related Messages .......................................................................................... B-38 B.9.1 LEOLUT/LEOSAT Availability Status .......................................................... B-39 B.9.2 LEOLUT/LEOSAT Location Accuracy Status .............................................. B-40 B.9.3 GEOLUT/GEOSAT Low Availability ........................................................... B-42 B.9.4 MEOLUT Location Accuracy Status Messages ............................................. B-44 B.9.5 MEOLUT Detection Probability Status Messages ......................................... B-46 B.9.6 MEOLUT Location Probability Status Messages........................................... B-46 B.9.7 MEOLUT Local Antenna Availability Status Messages ................................ B-48 B.9.8 MEOLUT Timeliness Status Messages .......................................................... B-48 ANNEX C : LOCATION DATA CONCEPTS AND TERMINOLOGY ............................ C-1 C.1 LEOSAR Doppler Solution Processing ............................................................ C-1 C.1.1.1 Doppler Curve ................................................................................................... C-1 C.1.2 A and B Positions.............................................................................................. C-2 C.1.2.1 LEOSAR Ambiguity Resolution ...................................................................... C-2 C.1.3 Time of Closest Approach (TCA)..................................................................... C-4 C.1.4 Cross-Track Angle (CTA) ................................................................................ C-4 C.1.5 Number of Points .............................................................................................. C-4 C.1.6 Window Factor.................................................................................................. C-5 C.1.7 Theoretical Number of Points for a Particular Satellite and CTA .................... C-7 C.1.8 Next Time of Visibility ..................................................................................... C-8 C.2 MEOSAR Difference of Arrival (DOA) Solution Processing ............................... C-8 C.2.1 Multilateration................................................................................................... C-8 C.2.2 Single Burst Solution ........................................................................................ C-9 C.2.3 Multi-Burst Solution ......................................................................................... C-9 C.2.4 MEOLUT Configuration ................................................................................ C-10 C.2.4.1 Networked Antennas ....................................................................................... C-10 C.2.5 MEOSAR Quality Assessment ....................................................................... C-11 C.2.6 Uncorroborated Alerts .................................................................................... C-11 C.3 Two-Line (Orbital) Elements (TLE)..................................................................... C-12 C.4 Moving Beacons ...................................................................................................... C-12 C.5 Independent Location Accuracy Estimates ......................................................... C-13 C.5.1 LEOSAR Error Ellipse ................................................................................... C-13 C.5.2 MEOSAR Expected Horizontal Error ............................................................ C-14 C.5.3 Confidence Factor (CF) .................................................................................. C-16 C.6 Large Location Errors and Possible Causes ........................................................ C-16 C.6.1 Encoded Location Data ................................................................................... C-17 C.6.2 Doppler Location Data .................................................................................... C-19 C.6.3 DOA Location Data ........................................................................................ C-20 ANNEX D : CONTINGENCY PROCEDURES .................................................................... D-1 D.1 Operational Backup ................................................................................................. D-1 D.1.1 Internal Back-up MCC ...................................................................................... D-2 D.1.2 Backup Another MCC ...................................................................................... D-2 D.1.3 Long Term Backup ........................................................................................... D-2 D.1.4 Backup in the Same DDR ................................................................................. D-3 D.1.4.1 Nodal MCC Backup ..................................................................................... D-4 D.1.4.2 Non-Nodal MCC Backup ............................................................................. D-4 D.1.5 Summary of Actions for MCC Scheduled and Contingency/Operational Backup D-6 D.2 LUT Data to Non-parent MCC ............................................................................... D-7 D.3 Use of Email for Transfer of SIT Messages ........................................................... D-8 D.4 Re-routing Alert Data between MCCs ................................................................... D-8 D.5 Special Procedures for the Transitional Phase-only ............................................. D-8 D.5.1 Encapsulation Procedure ................................................................................. D-10 D.5.2 Distribution of MEOSAR Alerts to LG MCCs............................................... D-10 D.5.3 Distribution of Second-Generation Beacon Alerts to FGB-Only MCCs........ D-11 D.5.4 Distribution of FGB-ELT(DT) Alerts to Non-FGB-ELT(DT) MCCs ........... D-11 D.5.5 Distribution of Alerts for RLS-Capable FGBs to Non-FGB-RLS MCCs ...... D-12 D.5.6 Distribution of RLSP Notifications ................................................................ D-12 D.5.7 Operational Distribution of Alert Data for SGBs and FGB ELT(DT)s .......... D-13 ANNEX E : SPECIALIZED REQUIREMENTS .................................................................. E-1 E.1 Nodal MCC ............................................................................................................... E-1 E.1.1 Requirements ..................................................................................................... E-1 E.1.2 Operations .......................................................................................................... E-1 E.2 Reference Beacon Provider ..................................................................................... E-2 E.3 Beacon Registry ........................................................................................................ E-3 E.4 Space Segment Provider .......................................................................................... E-3 E.5 Return Link Service Provider ................................................................................. E-5 E.5.1 SAR/Galileo RLS............................................................................................... E-6 ANNEX F : MONITORING AND TEST ACTIVITIES ....................................................... F-1 F.1 Commissioning Support............................................................................................ F-1 F.1.1 MCC Commissioning ........................................................................................ F-1 F.1.2 LUT Commissioning ......................................................................................... F-2 F.1.2.1 Notifying a LUT to ITU ..................................................................................... F-4 F.1.3 Space Segment Commissioning ......................................................................... F-4 F.2 MCC Annual Backup Test ....................................................................................... F-5 F.3 Monthly Communication Link Testing with SPOCs ............................................. F-6 F.4 Beacon Type Approval Tests .................................................................................... F-6 F.5 Interference Monitoring ........................................................................................... F-7 F.5.1 In-Band Interference .......................................................................................... F-7 F.5.2 Out-Of-Band Interference .................................................................................. F-8 ANNEX G : COSPAS-SARSAT MODEL COURSE ............................................................ G-1 G.1 Purpose of the Model Course .................................................................................. G-1 G.2 Training Resources................................................................................................... G-1 G.3 Detailed Outline ........................................................................................................ G-2 G.3.1 Concept of the Cospas-Sarsat System: ............................................................. G-2 G.3.2 Management of the Cospas-Sarsat Programme: ............................................... G-2 G.3.3 Space Segment (LEO, GEO and MEO):........................................................... G-3 G.3.4 Ground Segment: .............................................................................................. G-3 G.3.5 LUTs: ................................................................................................................ G-3 G.3.6 MCCs: ............................................................................................................... G-4 G.3.7 Cospas-Sarsat Data Distribution Procedures: ................................................... G-4 G.3.8 Cospas-Sarsat Message Formats: ...................................................................... G-5 G.3.9 Beacons: ............................................................................................................ G-6 G.3.10 Communications: .............................................................................................. G-7 G.3.11 Contingency Procedures: .................................................................................. G-8 G.3.12 Documentation Set: ........................................................................................... G-8 G.3.13 Competency Check: .......................................................................................... G-8 G.3.14 On-the-Job Training: ......................................................................................... G-8 G.3.14.1 Working Time Schedule: ............................................................................. G-9 G.3.14.2 Training Plan (subject to be covered): ......................................................... G-9 G.3.14.3 MCC Operator Checkout and Certification: .............................................. G-10 G.3.14.4 Recurrent Training/Recertification ............................................................ G-10 LIST OF FIGURES Figure 3.1: Flow of control .......................................................................................................... 3-2 Figure 3.2: Types of Cospas-Sarsat Distress Beacon .................................................................. 3-3 Figure 3.3: Cospas-Sarsat Distress Beacons ................................................................................ 3-4 Figure 3.4: Cospas-Sarsat Satellite Visibility .............................................................................. 3-7 Figure 4.1: Cospas-Sarsat Concept of Operations ....................................................................... 4-1 Figure 4.2: Typical Cospas-Sarsat MCC Functional Block Diagram.......................................... 4-2 Figure 4.3: Typical MCC Images ................................................................................................ 4-6 Figure 4.4: Cospas-Sarsat Data Distribution Network .............................................................. 4-11 Figure 4.5: IMO GISIS Maritime Security Website Interface ................................................... 4-29 Figure 6.1: Sample Narrative Message ........................................................................................ 6-4 Figure 6.2: Sample System Status Message ................................................................................ 6-5 Figure 6.3: Sample Notification of Communications Failure ...................................................... 6-9 Figure 6.4: Sample Message Re-Transmission Request ............................................................ 6-11 Figure 6.5: Sample Re-Transmitted Message ............................................................................ 6-12 Figure 6.6: Sample Message to Request Suppression of Beacon Alerts ................................... 6-14 Figure 6.7: Sample Message to Confirm Suppression of Beacon Alerts ................................... 6-14 Figure 6.8: Sample QMS Status Display ................................................................................... 6-17 Figure 6.9: Sample Message to Request Beacon Registration Data .......................................... 6-19 Figure 6.10: Sample Message to Report Beacon Registration Data .......................................... 6-20 Figure 6.11: Sample Message to Report No Beacon Registration Data .................................... 6-21 Figure 6.12: Sample Message to Announce a LEOSAR Satellite Manoeuvre .......................... 6-29 Figure 6.13: Sample Message to Announce a Planned Beacon Test Activation ....................... 6-35 Figure A.1: Alert Data Processing Concept ................................................................................ A-5 Figure A.2: Return Link Service ............................................................................................... A-15 Figure A.3: Distress Tracking Alert Support ............................................................................ A-17 Figure A.4: Flow of Cospas-Sarsat QMS Data ......................................................................... A-21 Figure B.1: Sample SIT 605 Announcement of MCC Backup ................................................ B-27 Figure B.2: Sample SIT 605 Announcement of MCC Backup ................................................ B-28 Figure B.3: Sample SIT 605 Announcement of MCC Backup ................................................ B-29 Figure B.4: Sample SIT 605 Announcement of MCC Resuming Operations .......................... B-29 Figure B.5: Sample SIT 605 Announcement of MCC Resuming Operations .......................... B-30 Figure B.6: Sample SIT 915 Notification of a Planned Beacon Test ....................................... B-31 Figure B.7: Sample SIT 915 Notification of a False Alert ....................................................... B-32 Figure B.8: Information Graphic on Sources of False Alerts ................................................... B-32 Figure B.9: Sample SIT 915 Notification of a Real Distress Incident...................................... B-33 Figure B.10: SIT 915 Location Accuracy Warning Message ................................................... B-34 Figure B.11: Sample SIT 605 Announcement of LEOSAR Location Accuracy Problem ....... B-36 Figure B.12: Sample SIT 915 Announcement of Doppler Location Filtering ......................... B-36 Figure B.13: Sample SIT 605 Announcement of LEOLUT/Satellite Conformity Status ........ B-37 Figure B.14: Sample SIT 605 Announcement of the Resumed Distribution of Doppler Solutions ........................................................................................................................... B-37 Figure C.1: A Sample Doppler Curve......................................................................................... C-1 Figure C.2: Unresolved Doppler Match Scenario....................................................................... C-3 Figure C.3: Window Factor Calculation ..................................................................................... C-6 Figure C.4: MEOSAR DOA Location Error ............................................................................ C-15 Figure C.5: Range Limits for DOA Location Error .................................................................. C-15 Figure C.6: DOA Location Error .............................................................................................. C-16 LIST OF TABLES Table 1-1 – Structure of the MCC Handbook .............................................................................. 1-2 Table 1-2 – Annexes to the MCC Handbook ............................................................................... 1-3 Table 2-1 – Space Segment Agreement Documents.................................................................... 2-3 Table 2-2 – Annexes to the Chicago Convention ........................................................................ 2-6 Table 2-3 – General Information Documents ............................................................................ 2-11 Table 2-4 – Programme Documents .......................................................................................... 2-12 Table 2-5 – Operational Documents .......................................................................................... 2-13 Table 2-6 – Technical Documents ............................................................................................. 2-13 Table 2-7 – IBRD Documents ................................................................................................... 2-14 Table 3-1 – Cospas-Sarsat Beacon Specifications ....................................................................... 3-4 Table 3-2 – Cospas-Sarsat Space Segment .................................................................................. 3-8 Table 4-1 – MCC Software Structure .......................................................................................... 4-7 Table 4-2 – Data Distribution Regions ...................................................................................... 4-10 Table 4-3 – Special Processing .................................................................................................. 4-18 Table 4-4 – System Data ............................................................................................................ 4-19 Table 4-5 – Network Annexes in the SID .................................................................................. 4-23 Table 5-1 – Beacon Type Approval Documents ........................................................................ 5-10 Table 6-1 – Sources of Satellite Orbit Data ............................................................................... 6-22 Table A-1: Subscripts used in Processing Matrices .................................................................... A-5 Table A-2 - Extract from MEOSAR Processing Matrix ............................................................. A-6 Table A-3: Processing Matrix Destination Codes ...................................................................... A-7 Table A-4: Essential Message Fields ........................................................................................ A-24 Table A-5: Solution Match Criteria .......................................................................................... A-28 Table A-6: Better Quality Solution Criteria .............................................................................. A-28 Table A-7: Bit Error Detection and Correction ........................................................................ A-30 Table A-8: System Data ............................................................................................................ A-32 Table B-1: Replacement Character Sequences ........................................................................... B-2 Table B-2: Alert Messages by Beacon Generation ..................................................................... B-2 Table B-3: LEOSAR and GEOSAR Alert Messages ................................................................. B-3 Table B-4: MEOSAR Alert Messages ........................................................................................ B-3 Table B-5: Message Control Fields ............................................................................................ B-6 Table B-6: Beacon Identification and Message Fields ............................................................... B-8 Table B-7: Solution Data Message Fields .................................................................................. B-8 Table B-8: Spacecraft Identification Codes .............................................................................. B-10 Table B-9: Solution Quality Data Message Fields ................................................................... B-13 Table B-10: Special Alert Message Formats ............................................................................ B-16 Table B-11: SARP Calibration Data Message Fields ............................................................... B-21 Table B-12: SARR Calibration Data Message Fields............................................................... B-21 Table B-13: SARP Control Message Formats .......................................................................... B-22 Table B-14: SARR Control Message Formats ......................................................................... B-22 Table B-15: SGB Information from TAC ................................................................................. B-25 Table B-16: Operational Message Templates ........................................................................... B-26 Table B-17: QMS Message Templates ..................................................................................... B-38 Table C-1: FGB Encoded Location Precision .......................................................................... C-18 Table D-1: MCC Backup Agreements ........................................................................................ D-5 Table D-2: MCC Backup Actions............................................................................................... D-6 Table E-1: Space Segment Providers and Contributors to the Space Segment ........................... E-4 Table F-1: LUT Commissioning Documents .............................................................................. F-3 Table F-2: Spacecraft Commissioning Documents ..................................................................... F-5 1-1 1. INTRODUCTION 1.1 Purpose This MCC Handbook is intended as a guide for the operational personnel at a Cospas-Sarsat Mission Control Centre (MCC), which is a key part of the Cospas-Sarsat System. The Cospas-Sarsat data distribution network, which is comprised of the Cospas-Sarsat MCCs, ensures that the incident alert data that has been generated by the System is sent to the appropriate authorities for action. The purpose of this MCC Handbook is to introduce new MCC operators and managers to the Cospas- Sarsat System and to describe the skills and competencies that are required of an MCC operator. It includes descriptions of the roles, responsibilities, and functions of an MCC and of the operators of the MCC. This Handbook should be used in conjunction with many other available resources, which may include one or more of: • the Cospas-Sarsat operational System documents, • the Cospas-Sarsat technical System documents, • Cospas-Sarsat training videos, • the model course described in an annex of document C/S P.015, “Cospas-Sarsat Quality Manual”, • other Cospas-Sarsat documents, • site-specific training and manuals that describe the regulations and the procedures that are established by the Ground Segment Provider responsible for this MCC, • vendor-specific training on the equipment that is used at this MCC. Note that all of the Cospas-Sarsat documents and videos are available on the Cospas-Sarsat website (at www.406.org). If any contradictions exist between this Handbook and another C/S document, then the associated information in the other C/S document should be considered to be true. The Cospas-Sarsat Secretariat should be notified of the discrepancy, so that the contradictory information can be corrected. An important role of this Handbook is to facilitate high-level understanding of the System through the associated documents. Any MCC operator training will require augmentation that is specific to national requirements. 1-2 1.2 Scope This Handbook is provided as a general guide to the operations of the MCCs of the Cospas-Sarsat System. More comprehensive and detailed specifications that describe the Mission Control Centre are contained in the operational documents. The specifications and descriptions of the other parts of the Cospas-Sarsat System are available in other System documents, many of which are identified in this Handbook. All of these System documents are available on the Cospas-Sarsat professional web sub-site under ; alternately, they can be obtained from the Cospas-Sarsat Secretariat. 1.3 Document Organization This MCC Handbook consists of six chapters, which provide the general outline of the information that is needed by an MCC operator. The body of this Handbook is supplemented by several Annexes that address specific aspects of an MCC. The structure of the body of this Handbook is outlined in Table 1-1. Table 1-1 – Structure of the MCC Handbook Chapter Description A general introduction to the document A general description of the Cospas-Sarsat Programme An overview and description of the operational concepts of the Cospas-Sarsat System A description of the Cospas-Sarsat MCC and a review of the requirements for an operational MCC A description of the operations that are required of a Cospas-Sarsat MCC A description of the functions that are expected to be performed by a Cospas- Sarsat MCC operator The Annexes to this MCC Handbook are included to provide more detailed explanations of specific aspects of a Cospas-Sarsat MCC and of its operation. These Annexes are listed in Table 1-2. 1-3 Table 1-2 – Annexes to the MCC Handbook Annexes A An explanation of the data distribution rules for incident alert data, as laid out in the Cospas-Sarsat Data Distribution Plan (document C/S A.001, the DDP) B A description of the Subject Indicator Type (SIT) messages that are defined in the Cospas-Sarsat Standard Interface Description (document C/S A.002, the SID) and that are used by the Cospas-Sarsat MCCs C An explanation of the location data concepts and the terminology that are used in connection with the Cospas-Sarsat Ground Segment, and more specifically with the incident alert data D A description of the contingency procedures that are used by MCCs in support of the Cospas-Sarsat data distribution system E An explanation of the unique requirements that apply to various specialized Cospas-Sarsat MCCs F A summary of the functions that an MCC is expected to provide in support of the Cospas-Sarsat Quality Management System and the Cospas-Sarsat System Monitoring and Reporting capabilities - END OF SECTION 1 – 2-1 2. THE COSPAS-SARSAT PROGRAMME 2.1 General The Cospas-Sarsat Programme operates a satellite-based beacon alert communication system in support of Search and Rescue (SAR) operations around the world. This System uses spacecraft and ground facilities to detect and locate distress signals from 406 MHz emergency beacons that are carried on boats and aircraft, and by individuals. The distress alert information derived from these beacon signals, including the position of the distress beacon and other related information (such as the information provided when the beacon was registered), is sent through the data distribution network, which is comprised of Cospas-Sarsat MCCs, to the appropriate SAR authorities. 2.2 History Search and Rescue has a long history of adapting the available technology to help those in distress. With the development of radio electronics after the Second World War, beacons were developed that enabled the operators of ships and airplanes to transmit distress signals to alert people that their vessel was in trouble, and to lead the rescuers to the scene of the incident. These beacons were designed to be heard through the radio receiver of an over-flying airplane. While this was a definite advance over previous capabilities, there remained many areas, such as the oceans and the far north, where there were not enough aircraft flying on a regular basis to make this a complete solution to the problem of identifying and locating distress incidents. The development of satellite technology in the nineteen sixties and seventies led researchers in several countries to look for a further advance: placing receivers on satellites to relay the signals to receiving ground stations. The culmination of this research in several countries was the Cospas- Sarsat System. During the twentieth century, there was also a strong movement towards the internationalization of many activities. The International Telegraph Union (formed in the middle of the nineteenth century) and the International Radiotelegraph Union (formed at the beginning of the twentieth century) combined in 1947 to form the International Telecommunication Union (ITU). Following on the Titanic disaster, the Safety of Life at Sea (SOLAS) convention and other international conventions eventually led to the establishment of the Inter-Governmental Maritime Consultative Organization (IMCO) in 1959, which was renamed the International Maritime Organization (IMO) in 1982. The Chicago Convention on International Civil Aviation, ratified in 1947, established the International Civil Aviation Organization (ICAO) to foster the planning and development of international air transport to ensure safe and orderly growth. All of these organizations have been established as organs of the United Nations. 2-2 The Search and Rescue Satellite-Aided Tracking (SARSAT) program began as a cooperative effort among the governments of Canada, France, and the United States of America (USA). At the same time, the government of the Union of Soviet Socialist Republics (USSR) was developing a similar program called Космическая система поиска аварийных судов, a Russian phrase that means Space System for the Rescue of Vessels in Distress. Transliterated from the Cyrillic it became Cosmicheskaya Sistema Poiska Avariynich Sudov, which was then abbreviated to COSPAS. Encouraged by the various international organizations that were involved in the organization of Search and Rescue (especially by ICAO and IMO, with support from ITU), these nations came together to discuss the sharing of this technology. In an agreement that was a significant accomplishment during the Cold-War era, a Memorandum of Understanding (MOU) was signed in 1979. This was followed by a second MOU in 1984, and then by the International Cospas-Sarsat Programme Agreement (ICSPA), which was signed by representatives of the four Party states (Canada, France, the USA, and the USSR) in July 1988 and subsequently ratified by each of their governments. The ICSPA provided a stable environment for other nations that wanted to participate in the Programme. By this agreement, the Parties agreed to provide their continued support for the space segment. Knowing that the space segment would be available, other countries could safely invest in the ground infrastructure that enabled them to participate in (and contribute to) the Programme. The original agreement was for fifteen years, and it provided for automatic extension at set intervals after that time. Although the USSR, one of the original signing Parties, was dissolved in 1991, the Russian Federation has assumed its place, and the agreement has continued without interruption. The ICSPA has been extended as required. As of 2023, the programme has grown to include forty-five participating countries and organizations. A complete list of Participants is maintained by the Cospas-Sarsat Secretariat in document C/S P.010, “List of States & Organizations Associated with or Contributing to the Cospas-Sarsat Programme”. The four Parties to the ICSPA each supply a part of the Space Segment for the System: • The USA supplies the satellite platforms and the launch capability for the SARSAT satellites. • Canada supplies the Search and Rescue Repeater instruments for the SARSAT satellites. • France supplies the Search and Rescue Processor instruments for the SARSAT satellites. • The Russian Federation supplies the COSPAS satellites, including all of the Search and Rescue payloads. Although the ICSPA was only written to address the LEOSAR system, it has been interpreted to allow the expansion to the GEOSAR and MEOSAR systems. Additional contributions to the Space Segment have been provided by the European Commission, India and China (P.R. of). Separate agreements have been signed to document these contributions to the Cospas-Sarsat System. These agreements are captured in individual documents, as listed in Table 2-1. The ICSPA is currently (in 2023) under review by the Parties, with a view to bringing it up to date with the current realities of the Programme. 2-3 Table 2-1 – Space Segment Agreement Documents Document Number Title P.008 Arrangement on Cooperation between Cooperating Agencies of Parties to the International C/S Programme Agreement and European Organisation for Exploitation of Meteorological Satellites (EUMETSAT) on EUMETSAT Contribution to C/S GEOSAR System P.009 Understanding Between States Parties to International C/S Programme Agreement and Republic of India Concerning Association of Republic of India with C/S Programme as a Provider of Geostationary Satellite Services for Search and Rescue (GEOSAR) P.014 Declaration of Intent for Co-operation on the Development and Evaluation of the Medium Earth Orbit Search and Rescue (MEOSAR) Satellite System between the Co-operating Agencies of the International Cospas-Sarsat Programme and the Galileo Joint Undertaking P.017 Declaration of Intent Between Co-operating Agencies of International C/S Programme and European Commission for Co-operation on Initial Operational Capability of C/S Medium-Altitude Earth Orbit Search and Rescue (MEOSAR) Satellite System P.018 Declaration of Intent with China for Co-Operation on MEOSAR; unsigned, courtesy translation. The original document was signed in the English, French and Russian languages, those versions all being equally authentic. The Cospas-Sarsat System was originally designed around the distress beacons that were in existence in the early 1980s, which transmitted a pulsed signal at 121.5 MHz. The signals from these beacons were intended to be detected by radio receivers on over-flying aircraft. They were designed neither for satellite relay nor for automated detection and processing. At that time there were about half a million of these beacons in operation and the System had to be made to work with them. The first prototype of the Cospas-Sarsat ground station (the Local User Terminal, or LUT) was designed and built by a Canadian company, in cooperation with the Canadian Communications Research Centre (CRC). This system showed that a computer could detect and locate emergency beacons by monitoring signals relayed over a satellite link. At the same time, the French space agency, CNES, was operating the Argos system for the detection and location of scientific platforms that carried specialized beacons. CNES believed that this capability should be incorporated into the new Cospas-Sarsat System; this led to the development of the specification for a new Cospas-Sarsat distress beacon, which would operate at 406 MHz. In 1985, there were only a few test beacons operating at this frequency; in 2023, the number of these beacons is estimated to have grown to over three million operational beacons. Since 2009 (when the satellite support for the 121.5 MHz beacons was turned off), the operational Cospas-Sarsat System detects and processes only the signals in the 406 MHz frequency band. 2-4 The first satellite of the Cospas-Sarsat System, Cospas-1, was launched by the USSR on 1 June 1982. At the time, there were only a few LUTs in operation, including those of the four founding Parties to the ICSPA. One of the key features of the ICSPA was the requirement that all of the national systems should be interoperable; that is, they should be capable of working together. This approach was confirmed on 10 September 1982, when the first Cospas-Sarsat rescue was based on data collected through a Soviet satellite (Cospas-1) and processed by the Canadian LUT. From the time of that first rescue to the end of 2019, the Cospas-Sarsat System has contributed to the Search and Rescue efforts in more than fifteen thousand distress incidents, during which more than fifty thousand people in distress have been rescued. For a more detailed description of the history of the Cospas-Sarsat Programme, the reader is referred to the document “The History and Experience of the International Cospas-Sarsat Programme for Satellite-Aided Search and Rescue”, which was prepared and edited by Daniel Levesque, the first Head of Cospas-Sarsat Secretariat. The document is available on the Cospas- Sarsat website under the tab: “History and Experience of the Programme”. 2.2.1 Stakeholder Organizations As noted in the description of the history of the Cospas-Sarsat System, above, three international organizations were deeply involved in the establishment of this System: • the International Civil Aviation Organization (ICAO), • the International Maritime Organization (IMO), • the International Telecommunications Union (ITU). Each of these organizations contributed to the establishment of the Cospas-Sarsat Programme; they are all major stakeholders in the Programme. As a part of their regulatory activities, ICAO and IMO prescribe the requirements for the carriage of Cospas-Sarsat distress beacons: Emergency Locator Transmitters (ELTs) and Emergency Position Indicating Radio Beacons (EPIRBs), on aircraft and ships, respectively. These requirements, as implemented by the member States of these organizations, are a driving force behind the use of these beacons around the world. ITU regulates the use of the frequency bands that are reserved for the use of the international search and rescue satellite system; as such, it is a major player in the management of the technical aspects of the Cospas-Sarsat System. These organizations, and their significance to the Cospas-Sarsat System, are described in the following sections. They each produce many documents; some of the documents that are relevant to the Cospas-Sarsat Programme are listed on the Cospas-Sarsat website, under the tab: select . 2-5 In particular, it should be noted that ICAO and IMO jointly publish the International Aeronautical and Maritime Search and Rescue (IAMSAR) Manual, which contains guidelines for Search and Rescue in terms of both shipping and aviation. The IAMSAR Manual consists of three volumes: • Volume I. Organization and Management, • Volume II. Mission Co-ordination, • Volume III. Mobile Facilities. The purpose of a common manual is to ensure that cooperation between the two areas of operation is effective, and that operational cooperation can be carried out in actual rescue operations between different organizational and rescue units. It is important to ensure smooth cooperation between the two areas because many ship and aircraft accidents involve both ships and aircraft in the search and rescue operations. The International Civil Aviation Organization The International Civil Aviation Organization (ICAO) was established in 1947 with the ratification of the Chicago Convention on International Civil Aviation (the Chicago Convention) by half of the States that had participated in the convention. Later that year, it became an agency of the United Nations. In 2023, essentially all of the countries of the world are member States of ICAO. More information about ICAO is available on its web site, at www.ICAO.int. ICAO, through its governing Council, adopts standards and recommendations for the regulation of many aspects of international air transport, including: • Air navigation and the supporting infrastructure, • Flight inspection, • Prevention of unlawful interference, • Facilitation of border-crossing procedures, • Air accident investigation. ICAO has updated the Chicago Convention several times since its original development and has established a series of Annexes to the convention, as listed in Table 2-2. ![Image 1 from page 23](/images/cospas-sarsat/G-series/G010/G010_page_23_img_1.png) 2-6 Table 2-2 – Annexes to the Chicago Convention Annex Title Personnel Licensing Rules of the Air Meteorological Service for International Air Navigation Aeronautical Charts Units of Measurement to be used in Air and Ground Operations Operation of Aircraft Aircraft Nationality and Registration Marks Airworthiness of Aircraft Facilitation Aeronautical Telecommunications Air Traffic Services Search and Rescue Aircraft Accident and Incident Investigation Aerodromes Aeronautical Information Services Environmental Protection Security The Safe Transport of Dangerous Goods by Air Safety Management With its long history of support for aviation-related SAR activities, as mandated by Annexes 11 and 12 to the Chicago Convention, ICAO has been supportive of the development of the Cospas- Sarsat Programme. The use of Cospas-Sarsat in many aviation incidents has established ICAO as a major stakeholder in the Programme. In response to several recent incidents, ICAO is in the process of developing the Global Aeronautical Distress and Safety System (GADSS). Amendments to the Annexes 6 and 12 have been approved, and the system is scheduled to be implemented early in the 2020s. The GADSS will apply to all international commercial aircraft, and will require: • automatic monitoring of aircraft position at fifteen-minute intervals, • in the event of a potential distress condition, autonomous monitoring of the aircraft position at one-minute intervals, • collection of information that will provide the location of a crash site within six nautical miles, • establishment of a Location of an Aircraft in Distress Repository (LADR), to be used by Airlines, Air Traffic Control Centres, and Rescue Coordination Centres to support aircraft that are in distress. Since ICAO is a major stakeholder in the Cospas-Sarsat System, the Programme is developing new technology, such as the distress tracking ELT(DT), and associated data distribution capabilities to support the GADSS initiative. 2-7 Section A.4.7.3 of this Handbook describes the features of the data distribution that will be supported for the distress tracking ELTs. The International Maritime Organization The International Maritime Organization (IMO) is a specialized agency of the United Nations which is responsible for regulating international shipping. IMO was established as the Inter- Governmental Maritime Consultative Organization (IMCO), following agreement at a UN conference held in Geneva in 1948, and it met for the first time in 1959. It became IMO in 1982. IMO was established to consolidate the international conventions which had previously been adopted piecemeal, such as the Safety of Life at Sea Convention (SOLAS), first adopted in 1914 following the Titanic disaster, and the International Convention for the Prevention of Pollution of the Sea by Oil (OILPOL). IMO has built on and expanded these (and other) agreements to develop and maintain a comprehensive regulatory framework for shipping. Its current responsibilities include safety, environmental concerns, legal matters, technical co-operation, maritime security and the efficiency of shipping. More information about IMO is available on its web site, at www.IMO.org. The membership of IMO consists (in 2023) of the 173 States which have ratified the Convention on the International Maritime Organization, including almost all of the member states of the United Nations that have a seacoast. The work of IMO that is related to Sea Safety and Search and Rescue is handled by the Maritime Safety Committee (MSC), which (under Article 28(a) of the Convention on the IMO): “shall consider any matter within the scope of the Organization concerned with aids to navigation, construction and equipment of vessels, manning from a safety standpoint, rules for the prevention of collisions, handling of dangerous cargoes, maritime safety procedures and requirements, hydrographic information, log-books and navigational records, marine casualty investigation, salvage and rescue, and any other matters directly affecting maritime safety.” The Sub-Committee on Navigation, Communications and Search and Rescue (NCSR) supports the MSC in the development of regulations and procedures related to Search and Rescue. The Global Maritime Distress and Safety System (GMDSS) is an internationally agreed-upon set of safety procedures, types of equipment, and communication protocols used to increase safety and make it easier to rescue distressed ships, boats and aircraft. In 1988, IMO amended the Safety of Life at Sea (SOLAS) Convention to require the ships that are subject to that convention (essentially, all large commercial shipping) to carry GMDSS equipment. Among other items, this equipment includes the 406 MHz satellite EPIRBs (Emergency Position Indicating Radio Beacons) that are supported by the Cospas-Sarsat System. This equipment has been required on all SOLAS ships since 1999. With the implementation of the GMDSS, the Cospas-Sarsat System has become an essential part of IMO regulations for the safety of shipping at sea. ![Image 1 from page 25](/images/cospas-sarsat/G-series/G010/G010_page_25_img_1.png) 2-8 The International Telecommunications Union The International Telecommunication Union (ITU) is a specialized agency of the United Nations that is responsible for issues that concern information and communication technologies. ITU coordinates the shared global use of the radio spectrum, promotes international cooperation in assigning satellite orbits, works to improve telecommunication infrastructure in the developing world, and assists in the development and coordination of worldwide technical standards. ITU is also active in the areas of broadband Internet, latest-generation wireless technologies, aeronautical and maritime navigation, radio astronomy, satellite-based meteorology, convergence in fixed- mobile phone, Internet access, data, voice, TV broadcasting, and next-generation networks. More information about ITU is available on its web site, at www.ITU.int. ITU grew out of the International Telegraph Union (established by the International Telegraph Convention agreed in Paris in 1865) and the International Radiotelegraph Union (established in 1906 at the first International Radiotelegraph Convention in Berlin). In 1932, a joint conference decided that the Telegraph Convention of 1875 and the Radiotelegraph Convention of 1927 were to be combined into a single convention, the International Telecommunication Convention, embracing the three fields of telegraphy, telephony and radio. The two organizations were merged into a single entity, the International Telecommunication Union. In 1947, an agreement between ITU and the newly created United Nations recognized ITU as the specialized agency for global telecommunications, and on 1 January 1949, ITU officially became an organ of the United Nations. In 2023, virtually all the member States of the United Nations are members of ITU. The Sector of ITU that is responsible for radio communication is ITU-R. Established in 1927 as the International Radio Consultative Committee (the CCIR, from its French name: Comité consultatif international pour la radio), the CCIR became (in 1992) ITU-R. This Sector of ITU manages the international radio-frequency spectrum and satellite orbit resources. Of particular interest to the Cospas-Sarsat programme, ITU-R is the body that authorizes the use of the frequency bands for satellite-based Search and Rescue communications, and that issues the recommendations for the protection of those frequency bands: • The uplink spectrum between 406.0 and 406.1 MHz: - Recommendation ITU-R M.633-4: Transmission Characteristics of a Satellite Emergency Position-Indicating Radio Beacon (Satellite EPIRB) System Operating through a Satellite System in the 406 MHz Band, - Recommendation ITU-R M.1478-3: Protection Criteria for Cospas-Sarsat Search and Rescue Instruments in the Band 406.0-406.1 MHz, - Recommendation ITU-R SM.1051-4: Priority of Identifying and Eliminating Harmful Interference in the Frequency Band 406.0-406.1 MHz and Monitoring in the Adjacent Frequency Bands 405.9 406.0 MHz and 406.1-406.2 MHz, - Report ITU-R M. 2359-0: Protection of the 406.0-406.1 MHz Band, • The downlink spectrum between 1,544.0 and 1545.0 MHz: ![Image 1 from page 26](/images/cospas-sarsat/G-series/G010/G010_page_26_img_1.png) 2-9 - Recommendation ITU-R M.1731-2: Protection Criteria for Cospas-Sarsat Local User Terminals in the Band 1,544.0 to 1,545.0 MHz. These Recommendations identify and allocate these frequency bands for use in support of satellite- based Search and Rescue and ask all the member States of ITU to monitor and protect these bands from unauthorized usage. In the context of their role as coordinator for the use of the radio spectrum, ITU requests that Space Segment and Ground Segment operators register their spacecraft and LUTs to formally benefit from the protection of the 1544.5-MHz satellite-to-LUT downlink frequency band (ITU-R M.1731). Administrations that operate MCCs should support the registration of all associated LUTs, liaising with their national ITU representative. When a LUT is officially declared at ITU, any interference noted in the received frequency of the LUT could be brought to ITU and resolved in accordance with appropriate ITU procedures (see also document C/S A.003 section 5 “Interference Monitoring” for reporting interference). When a LUT has not been declared to ITU this process is less efficient. The LUT specification documents C/S T.005 (LEOLUTs), C/S T.010 (GEOLUTs) and C/S T.020 (MEOLUTs) each contain a section 2.4 “Frequency Registration” and an Annex H “Guidelines for Registration of New […]LUTs with ITU”. Additional information can be found on the ITU web site (www.itu.int). In support of ITU, many of the Participants in the Cospas-Sarsat System, especially those who are Ground Segment Providers, monitor the protected Cospas-Sarsat frequencies, and report to ITU when any unauthorized interference is detected. Although ITU does not, in itself, have any enforcement powers, it can (and does) exert influence on the regulatory agencies in the participating States that can (and do) enforce the laws by which the States implement these recommendations. 2.3 Cospas-Sarsat Website Cospas-Sarsat maintains a website on which it publishes information about the System and other information that may be of interest to its users and operators. It can be accessed at the Cospas- Sarsat home page, http://www.cospas-sarsat.int. The website is divided into two sub-sites: • the Cospas-Sarsat regular web sub-site, • the Cospas-Sarsat professional web sub-site. The regular web sub-site is directed at the general public and to users of the System. Under the tabs on the front page, this sub-site contains: • Information about the acquisition and use of a Cospas-Sarsat 406 MHz distress beacon, • A description of the Cospas-Sarsat System for the general audience, 2-10 • Access to some of the documents that provide general information about the System, • Information about the structure and organization of the Cospas-Sarsat programme. The Cospas-Sarsat professional web sub-site is directed at the professionals (and others) who work with the Cospas-Sarsat System. To access this professional web sub-site, go to the Cospas-Sarsat home page and select the button. The tabs on the front page of the Cospas-Sarsat professional website give access to a great deal of additional information about the Cospas-Sarsat System, including: • Descriptions of the current status of the various components of the System: - The status of the Space Segment, - A detailed description of the LEOSAR and GEOSAR systems, - The Cospas-Sarsat Quality Management System (QMS), - Supplementary information about the MEOSAR system. • Descriptions of the support available for Cospas-Sarsat 406 MHz beacons: - The registration of a distress beacon, - General information about the carriage and regulation of distress beacons, - A program to decode the digital message sent by a beacon. • A list of all of the System documents (see section 2.4 of this Handbook). • The schedule of meetings, including for each meeting: - the papers submitted for discussion, - the report of the meeting. • - Information about all the Cospas-Sarsat Mission Control Centres, - Information about other web sites that may be of interest, - Contact information for the Cospas-Sarsat Secretariat. 2-11 Some of the information on the professional web sub-site is protected by account and password access. Accounts are available to authorized agencies and personnel and are issued (and annually renewed) by the Cospas-Sarsat Secretariat to official Representatives. These Representatives then distribute the passwords as required within their national programmes. The Cospas-Sarsat documents that are referenced in this MCC Handbook are all available on the Cospas-Sarsat professional web sub-site (under the tab). 2.4 Cospas-Sarsat Reference Documents The tables in the following sections of this Handbook contain lists of the Cospas-Sarsat documents that are referenced in this MCC Handbook; these documents are recommended for a more complete understanding of the operation of a Cospas-Sarsat MCC. The acronyms and other Cospas-Sarsat terminology that are used in this Handbook (and in many other Cospas-Sarsat documents) are defined in document C/S S.011, “Cospas-Sarsat Glossary”. Many (but not all) of the Cospas-Sarsat System documents (including the glossary) are available in all three of the official languages of the Programme (English, French, and Russian). Some of the documents are also available in other languages, with translations provided by some of the Participants in the Cospas-Sarsat System. A complete list of the Cospas-Sarsat System documents, as well as the text of each of the documents, is available on the Cospas-Sarsat professional web sub-site (under the tab). 2.4.1 General Reference Documents The documents that are listed in Table 2-3 provide general information for users of the System. Table 2-3 – General Information Documents Document Number Title G.003 Introduction to Cospas-Sarsat G.005 Cospas-Sarsat Guidelines on 406 MHz Beacon Coding, Registration and Type Approval G.007 Handbook on Distress Alert Messages for Rescue Coordination Centres (RCCs), Search and Rescue Points of Contact (SPOCs) and IMO Ship Security Competent Authorities G.010 MCC Handbook S.007 Handbook of Beacon Regulations S.011 Cospas-Sarsat Glossary 2-12 The document C/S G.003 is a general introduction to the Programme and to the System; it is directed at people who are new to and not familiar with the Programme. The document C/S G.005 provides information about how the data should be encoded in a Cospas- Sarsat 406 MHz distress beacon. The document C/S G.007 contains the descriptions and explanations of the contents of the distress alert message that are sent to the RCCs and SPOCs by the Cospas-Sarsat MCCs. These are the SIT 185 messages, and this information supplements the explanations of the SIT messages in ANNEX B of this Handbook. The document C/S S.007 provides a list of information, provided by Participating States of the Cospas-Sarsat Programme, on the regulations that are imposed by various nations for the encoding and operation of 406 MHz distress beacons. This Handbook is maintained by the Cospas-Sarsat Secretariat from the contributions provided by each of the States that regulates the use of these beacons. The document C/S S.011 includes information about all the acronyms and about many of the terms that are specific to the Cospas-Sarsat Programme. Cospas-Sarsat also publishes some other documents of general interest: • the Information Bulletin contains information about the current status of the System, • the System Data Document contains specific detailed information about the various components of the Cospas-Sarsat System. These documents are issued at regular intervals by the Cospas-Sarsat Secretariat; they are also available on the Cospas-Sarsat professional web sub-site. 2.4.2 Programme Documents Table 2-4 contains a list of the Programme documents that are referenced in this Handbook, and that describe the organizational structure of the Cospas-Sarsat System. The Programme documents also include the agreements that have been signed with the Space Segment providers, as listed in Table 2-1. Table 2-4 – Programme Documents Document Number Title P.001 International Cospas-Sarsat Programme Agreement P.002 Procedure for the Notification of Association with the International Cospas- Sarsat Programme by States Non-Party to the Cospas-Sarsat Agreement P.007 Guidelines for Participating in the Cospas-Sarsat System 2-13 P.010 List of States & Organizations Associated with or Contributing to the Cospas- Sarsat Programme P.011 Cospas-Sarsat Programme Management Policy P.015 Cospas-Sarsat Quality Manual 2.4.3 Operational Documents Table 2-5 is a list of the operational documents for the Cospas-Sarsat System. These documents describe the Cospas-Sarsat Data Distribution System and contain the essential details of the operational requirements for a Cospas-Sarsat Mission Control Centre. Table 2-5 – Operational Documents Document Number Title A.001 Cospas-Sarsat Data Distribution Plan A.002 Cospas-Sarsat Standard Interface Description A.003 Cospas-Sarsat System Monitoring and Reporting A.005 Cospas-Sarsat Mission Control Centre Performance Specification and Design Guidelines A.006 MCC Commissioning Standard 2.4.4 Technical Documents The documents that are listed in Table 2-6 address the technical components of the Cospas-Sarsat System; in particular, they define and describe the 406 MHz distress beacons, the Cospas-Sarsat Space Segment, and the Local User Terminals of the Cospas-Sarsat Ground segment. Table 2-6 – Technical Documents Document Number Title T.001 Specification for [First-Generation] Cospas-Sarsat 406 MHz Distress Beacons T.002 Cospas-Sarsat Local User Terminal [LEOLUT] Performance Specification and Design Guidelines T.003 Description of the 406-MHz Payloads Used in the Cospas-Sarsat LEOSAR System T.004 Cospas-Sarsat LEOSAR Space Segment Commissioning Standard T.005 Cospas-Sarsat LEOLUT Commissioning Standard T.006 Cospas-Sarsat Orbitography Network Specification 2-14 Document Number Title T.007 Cospas-Sarsat 406 MHz [First-Generation] Distress Beacon Type Approval Standard T.009 Cospas-Sarsat GEOLUT Performance Specification and Design Guidelines T.010 Cospas-Sarsat GEOLUT Commissioning Standard T.011 Description of the 406-MHz Payloads Used in the Cospas-Sarsat GEOSAR System T.012 Cospas-Sarsat 406 MHz Frequency Management Plan T.013 Cospas-Sarsat GEOSAR Space Segment Commissioning Standard T.015 Cospas-Sarsat Specification and Type Approval Standard for 406 MHz Ship Security Alert (SSAS) Beacons T.016 Description of the 406-MHz Payloads Used in the Cospas-Sarsat GEOSAR System T.017 Cospas-Sarsat MEOSAR Space Segment Commissioning Standard T.018 Specification for Second-Generation Cospas-Sarsat 406 MHz Distress Beacons T.019 Cospas-Sarsat MEOLUT Performance Specification and Design Guidelines T.020 Cospas-Sarsat MEOLUT Commissioning Standard T.021 Cospas-Sarsat Second-Generation 406-MHz Distress Beacon Type Approval Standard T.022 Cospas-Sarsat MEOSAR Reference Beacon Network Design Guidelines 2.4.5 IBRD Documents The documents that are listed in Table 2-7 address the requirements and operations of the Cospas- Sarsat International 406 MHz Beacon Registration Database (IBRD). Table 2-7 – IBRD Documents Document Number Title D.001 Functional Requirements for the Cospas-Sarsat International 406 MHz Beacon Registration Database D.004 Operations Plan for the Cospas-Sarsat International 406 MHz Beacon Registration Database 2.4.6 Cospas-Sarsat Videos The Cospas-Sarsat organization has developed a number of video clips that describe and provide more information about various aspects of the System. Each of these video clips is relatively short, 2-15 with a play time between one and fifteen minutes. Most of these videos are available in English with French and Russian subtitles. Some videos are also available with Arabic, Greek, Portuguese and Spanish subtitles. To access any of these videos, go to the Cospas-Sarsat regular web sub-site and select and ; then select and play the video that you want to watch. Some of the topics that are addressed in these videos include: • an introduction to and an overview of the Cospas-Sarsat System, • explanations of why a person should buy a 406 MHz beacon and of how it should be used, • descriptions of how the System works and of various components of the System, • a series of frequently asked questions (FAQs) about the Programme and about the System. The Media Gallery on the Regular web sub-site includes (under ) a complete list of the videos that are available at any time. - END OF SECTION 2 - 3-1 3. OVERVIEW OF THE COSPAS-SARSAT SYSTEM Cospas-Sarsat is an international programme that has developed and that operates a satellite-based system for the detection and location of distress beacons anywhere in the world. 3.1 Mission Statement “The International Cospas-Sarsat Programme provides accurate, timely and reliable distress alert and location data to help search and rescue authorities assist persons in distress.” As stated in the dedication of document C/S P.001, “International Cospas-Sarsat Programme Agreement” (the ICSPA,), this alert and location data is provided on a non-discriminatory basis: • It is generated in response to the detection of any beacon, regardless of the nationality of the person who owns or operates the distress beacon. • It is distributed, based on the location and the country of registration of the beacon, to the SAR authorities of the appropriate State(s), regardless of whether they have associated themselves with the Programme. 3.2 Introduction The Cospas-Sarsat System uses distress beacons, which transmit signals in the 406 MHz frequency band that are received by search and rescue instruments on the satellites used by the System. As illustrated in Figure 3.1, the signals from active distress beacons are relayed through the satellites to Cospas-Sarsat ground receiving stations, called Local User Terminals (LUTs), which process the signals to extract the beacon identification data and to determine the location of the beacon. Each LUT is associated with a Mission Control Centre (MCC) to which the alert data is forwarded and by which it is then relayed, through a data distribution network of MCCs, to the appropriate SAR point of contact (SPOC), Rescue Co-ordination Centre (RCC), or other authority, who is then responsible for the necessary search and rescue activities. 3-2 Figure 3.1: Flow of control This illustration shows, very briefly, what happens when a 406 beacon is activated. 3.3 Beacon Segment The Cospas-Sarsat Beacon Segment consists of the 406 MHz distress beacons that are carried on ships and aircraft, or that are carried by individuals who expect to be in other situations where they may require assistance. As of 2023, there are over three million 406 MHz distress beacons available for operational use around the world. The types of Cospas-Sarsat 406 MHz distress beacons that are used by the Cospas-Sarsat System include: • Emergency Locator Transmitters (ELTs, for use on aircraft), including distress-tracking ELT(DT) beacons, • Emergency Position Indicating Radio Beacons (EPIRBs, for use on ships), including Ship Security Alerting System (SSAS) beacons, • Personal Locator Beacons (PLBs, for use in multiple environments by individuals). Some examples of each of these types of beacons are illustrated in Figure 3.2. Many of these beacons are activated automatically in the event of an accident. Others are designed to be triggered manually; however, once they have been activated, they will transmit their distress messages with no further intervention. ![Image 1 from page 35](/images/cospas-sarsat/G-series/G010/G010_page_35_img_1.png) 3-3 Figure 3.2: Types of Cospas-Sarsat Distress Beacon The different types of beacons are designed for use in different environments: • Aviation: Emergency Locator Transmitter (ELT) and Distress Tracking ELT(DT) (for tracking aircraft in potential distress situations), • Maritime: Emergency Position-Indicating Radio Beacon (EPIRB) and Ship Security Alerting System (SSAS) beacon (for security situations on SOLAS vessels), and • Individual: Personal Locator Beacon (PLB) (not necessarily linked to an aircraft or a ship). ![Image 1 from page 36](/images/cospas-sarsat/G-series/G010/G010_page_36_img_1.png) 3-4 Figure 3.3: Cospas-Sarsat Distress Beacons The beacons shown in this illustration are examples of the Cospas-Sarsat distress beacons that are in use in various environments, including maritime EPIRBs, aviation ELTs, and personal PLBs. The photographs in Figure 3.3 show examples of some of the Cospas-Sarsat distress beacons that are in operational use with the System in various environments around the world. The specifications for the distress beacons that are detected and located by the Cospas-Sarsat System are contained in the documents that are listed in Table 3-1. These include both the actual distress beacons (identified as “Distress” in the table) and a range of supporting beacon types (identified as “Support” in the table). Table 3-1 – Cospas-Sarsat Beacon Specifications Document Type Title C/S T.001 Distress Specification for [First-Generation] Cospas-Sarsat 406 MHz Distress Beacons C/S T.006 Support Cospas-Sarsat Orbitography Network Specification C/S T.015 Distress Cospas-Sarsat Specification and Type Approval Standard for 406 MHz Ship Security Alert (SSAS) Beacons C/S T.018 Distress Specification for Second-Generation Cospas-Sarsat 406 MHz Distress Beacons C/S T.022 Support Cospas-Sarsat MEOSAR Reference Beacon Network Design Guidelines Document C/S T.012, “Cospas-Sarsat 406 MHz Frequency Management Plan”, describes the allocation of frequency channels within the 406 MHz frequency band that is allocated (by ITU) for the transmission of distress signals to satellite systems for the support of Search and Rescue. ![Image 1 from page 37](/images/cospas-sarsat/G-series/G010/G010_page_37_img_1.png) ![Image 2 from page 37](/images/cospas-sarsat/G-series/G010/G010_page_37_img_2.png) ![Image 3 from page 37](/images/cospas-sarsat/G-series/G010/G010_page_37_img_3.png) 3-5 ICAO and IMO, as well as Cospas-Sarsat, require that all nations that support the use of distress beacons maintain a register of these beacons. For each beacon, the beacon registry should contain: • the beacon’s unique identifier, • the beacon country code, • the beacon type (ELT, EPIRB, or PLB), • the identification of the vessel on which the beacon is carried: - for an EPIRB, the ship that carries the beacon, - for an ELT, the aircraft on which the beacon is installed, - for a PLB, the person who will be carrying the beacon, • information about the type of vessel on which the beacon is carried; for example, the number of people on board and the size and type of the vessel, • contact information for a person who should be aware of the use of this beacon (and who should be available if the beacon is activated). In addition, any other information that may be of use to the Search and Rescue personnel in the event of a distress incident could be included in the beacon registry. To support those nations which do not have their own beacon registry, the Cospas-Sarsat Programme operates an International Beacon Registration Database (IBRD, at 406registration.com). This database, which is maintained by the Cospas-Sarsat Secretariat, allows countries to designate the IBRD as their beacon registry. It is available free of charge to the owner and operator of the beacon. It provides twenty-four-hour access to the beacon registration information that is provided by the owner of the beacon, for the use of MCCs and RCCs in support of their SAR activities. Document C/S D.004, “Operations Plan for the Cospas-Sarsat International 406 MHz Beacon Registration Database”, provides information about the IBRD. 3.4 Space Segment The Cospas-Sarsat Space Segment includes all the spacecraft that are used by the System. This includes spacecraft that are in three different types of orbit around the Earth: • LEOSAR spacecraft are in Low-Altitude Earth Orbit (LEO), at altitudes between 700 km and 1000 km above the surface of the Earth. These spacecraft carry two types of Search and Rescue instruments: - The Search and Rescue Repeaters (SARRs) receive and relay the beacon signals immediately to any LEOLUT that is within the visibility region below the satellite when the beacon is active. This provides a local coverage capability in the area around each LEOLUT. - The Search and Rescue Processors (SARPs) receive and measure the beacon signals; they have a store-and-forward capability that enables them to store and later transmit 3-6 the signals to any LEOLUT that is in view of the satellite. This capability provides the LEOSAR system with global coverage. • MEOSAR spacecraft are in Medium-Altitude Earth Orbit (MEO), at altitudes between 20,000 km and 24,000 km above the surface of the Earth. Each MEOSAR satellite carries a SARR instrument that will relay any 406 MHz beacon signal that it receives to all MEOLUTs that are visible to it. Because of the wide area that is visible to each of the MEOSAR satellites, this is sufficient to provide global coverage with a relatively small number of operational MEOLUTs. • GEOSAR spacecraft are in Geostationary Earth Orbit (GEO), at altitudes of approximately thirty-six thousand kilometres above the surface of the Earth. Each GEOSAR satellite carries a SARR instrument that will relay any 406 MHz beacon signal that it receives to all GEOLUTs that are tracking it. With a relatively small number of satellites and GEOLUTs, the GEOSAR system provides complete global coverage for all regions below about 70° latitude. However, the GEOSAR system does not provide any independent location capability; the only location data available through the GEOSAR system is the encoded location that may be provided in the beacon message. The illustrations in Figure 3.4 provide a visual comparison of the relative visibility areas of the satellites of each of the constellations used in the Cospas-Sarsat Space Segment. 3-7 Figure 3.4: Cospas-Sarsat Satellite Visibility These diagrams illustrate the area of the surface of the Earth that is visible to a satellite of each of the Space Segment. Each LEOSAR satellite provides visibility for approximately 4% of the Earth’s surface, MEOSAR 35% and GEOSAR 38%. In 2023, the LEOSAR and GEOSAR systems are fully operational, and the MEOSAR system is at an Initial Operational Capability (IOC). The Space Segment Providers for the operational satellites in each of these Space Segments are identified in Table 3-2. The number of operational satellites in each part of the Cospas-Sarsat Space Segment is available on the Cospas-Sarsat website, under the tab: “Current Space Segment Status and SAR Payloads”. ![Image 1 from page 40](/images/cospas-sarsat/G-series/G010/G010_page_40_img_1.png) 3-8 Table 3-2 – Cospas-Sarsat Space Segment Segment Satellites Space Segment Provider LEOSAR SARSAT\* COSPAS Canada / France / USA Russian Federation MEOSAR SAR/Galileo SAR/Glonass SAR/GPS DASS European Commission Russian Federation Canada / USA United States of America GEOSAR GOES MSG MTG INSAT Louch Electro-L United States of America European Commission European Commission India Russian Federation Russian Federation Note that, in addition to the operational satellites that are listed on the web site, there are frequently additional satellites that are in various stages of preparation and test, including several on-orbit standby satellites that are ready for operation whenever they may be called on. 3.5 Ground Segment The Cospas-Sarsat Ground Segment is comprised of: • A network of satellite ground stations, called Local User Terminals (LUTs): - Low Earth Orbit Local User Terminals (LEOLUTs) A LEOLUT tracks each LEOSAR satellite that passes over it and receives the downlink signals from it. It detects and extracts the beacon messages from these downlink signals and determines the time and frequency when each beacon message is received at the spacecraft: ▪ For SARP data, it extracts the measurements from the Processed Data Stream that is sent from the SARP instrument, ▪ For the SARR data, it measures the time and frequency when the data is received at the LEOLUT, and corrects it to compute the values that would apply at the spacecraft. Using this data, it performs Doppler location processing to determine an independent location estimate for the beacon. * For the Sarsat LEOSAR satellites, Canada provides the SARR instruments, France provides the SARP instruments, and the USA provides the satellite platforms. 3-9 - Medium Earth Orbit Local User Terminals (MEOLUTs) A MEOLUT tracks as many MEOSAR satellites as it can and receives the downlink signals from them. (Because a MEOLUT must track multiple satellites simultaneously, many MEOLUTs use phased-array antennas that can be software-controlled to support several independent antenna beam patterns from one antenna.) The MEOLUT detects and extracts the beacon messages from these downlink signals and measures the time and frequency when each beacon message is received. Using this data, it performs the Difference of Arrival (DOA) location processing to determine an independent location estimate for the beacon. - Geosynchronous Earth Orbit Local User Terminals (GEOLUTs) A GEOLUT usually tracks a single GEOSAR satellite and receives the downlink signals. It detects and extracts the beacon messages from these downlink signals and measures the time and frequency when each beacon message is received. However, because the GEOSAR satellites have negligible motion relative to the GEOLUT, the GEOLUT cannot determine an independent location estimate for the beacon. Each LUT is associated with a Mission Control Centre (MCC). For each beacon that it detects, the LUT sends the solution data to its associated MCC. This solution data includes the beacon message; if the beacon message includes an encoded position estimate, that data is included in the message that goes to the MCC. • A network of Mission Control Centres A Cospas-Sarsat MCC is the focal point for the System operations in each Ground Segment Provider State. All the MCCs are connected through a network of communications links. Together, this network of MCCs comprises the Cospas-Sarsat data distribution system, which is capable of sending the incident alert data generated by the LUTs to the Search and Rescue authorities who are responsible for responding to the distress situation and rescuing the people who are at risk. The Cospas-Sarsat Ground Segment (in 2023) consisted of 32 Mission Control Centres (MCCs) in operation and more than 100 Local User Terminals (LUTs). A complete list of Ground Segment Providers is available in document C/S P.010, “List of States & Organizations Associated with or Contributing to the Cospas-Sarsat Programme”. At any time, the list of operational MCCs and of operational LEOLUTs and GEOLUTs is available on the Cospas-Sarsat website, under the tab: “List of LEOLUTs/GEOLUTs”. As the MEOSAR system becomes operational, the list of MEOLUTs has been added to the website. - END OF SECTION 3 - 4-1 4. THE MISSION CONTROL CENTRE 4.1 Overview A Mission Control Centre (MCC) in the Cospas-Sarsat Ground Segment is defined as a functional entity; there is no Cospas-Sarsat specification for how an MCC should be implemented. Although there is no explicit requirement that the MCC should be automated, every operational MCC in the Cospas-Sarsat System includes a computer system that manages the processing and distribution of data through that MCC. Figure 4.1 illustrates the Concept of Operation of the Cospas-Sarsat System and shows where the Mission Control Centre fits in this concept. Figure 4.1: Cospas-Sarsat Concept of Operations This diagram illustrates the Concept of Operations of the Cospas-Sarsat System, showing the MCC among the different components of the System. 4.1.1 Functions of an MCC Figure 4.2 is a functional block diagram for a typical MCC, and the illustrations in Figure 4.3 show some of the equipment that is included in a typical MCC system. ![Image 1 from page 43](/images/cospas-sarsat/G-series/G010/G010_page_43_img_1.png) 4-2 Figure 4.2: Typical Cospas-Sarsat MCC Functional Block Diagram This diagram is based on the layout shown in document C/S A.005, “Cospas-Sarsat Mission Control Centre Performance Specification and Design Guidelines” The requirements for a Cospas-Sarsat MCC are described in document C/S A.005, “Cospas-Sarsat Mission Control Centre Performance Specification and Design Guidelines”. 4.1.2 Operational Requirements The operational requirements for a Cospas-Sarsat MCC are listed in Chapter 3 of the MCC Specifications. In addition to the general requirements for an MCC, these operational requirements include: • Availability: An MCC is a critical part of the Cospas-Sarsat System, which is required to be available and accessible at all times. • LUT Coordination: For a Ground Segment Provider that operates one or more LUTs, the MCC is responsible for the coordination of the LUT operations with the rest of the Cospas- Sarsat System. • Data Communication Links: As a key component of the Cospas-Sarsat data distribution network, the MCC is responsible for the maintenance and operation of the communication links that connect it to the other MCCs and to the local Search and Rescue agencies or other responsible authorities in the area that it serves. ![Image 1 from page 44](/images/cospas-sarsat/G-series/G010/G010_page_44_img_1.png) 4-3 • Data Formats: The MCC is expected to communicate with other MCCs and with Search and Rescue Points of Contact (SPOCs) using the message formats and protocols that are defined in document C/S A.002, “Cospas-Sarsat Mission Control Centres Standard Interface Description” (the SID,). Although there is no specification for the communications that are to be used with national LUTs, RCCs, or other competent authorities, most MCCs use similar network facilities, including the message protocols and message formats described in the SID, to communicate with these authorities. • Monitoring of National Ground Segment: An MCC supports the ground segment capabilities of the Ground Segment Provider that operates the MCC. As such, it is responsible to monitor all components of its national ground segment. More information about the system monitoring that is done by an MCC is contained in section 5.3 of this Handbook. • Backup Provisions: In order to meet the availability requirements of the MCC specification, each MCC is expected to have in place suitable arrangements for backup capability, to be put into effect whenever the MCC cannot perform to specification. These backup provisions are addressed further in sections 5.2.5 and D.1 of this Handbook. • Re-routing of Messages: Per bilateral agreement, an MCC may re-route messages for another MCC. • Beacon Register: As noted above, every nation is expected to provide for the registration of distress beacons that are encoded with that nation’s country code. This may be done by maintaining a separate national beacon registry or by authorizing the registration of these beacons in the Cospas-Sarsat IBRD. In either case, the MCC is responsible to maintain access to the beacon register and to provide the beacon registration data to any other MCC that may request that information. • Information Archival and Retrieval: As a key operational part of the international Search and Rescue facilities, each MCC is required to maintain an archive of information concerning all incident alert data and all messages that it has transmitted or received. The information that is received by the MCC, including all distress alerts and the associated information, is maintained in a database, and must be available on request. • Test and Exercise Coordination and Reporting: An MCC is required to support any tests or exercises of the Cospas-Sarsat System, or of the various component parts of that System, that may be approved by the appropriate authorities. After each such test or exercise, the MCC may have to prepare a suitable report of the events and results of the activity. • Interference Control: An MCC is responsible for the coordination and reporting of any frequency monitoring activity conducted by the Ground Segment Provider that operates the MCC. This specifically includes the reporting of any detected interference in the frequency bands that are reserved for the use of the Cospas-Sarsat System, either to the national regulatory authorities or to ITU (or to both, as appropriate). 4-4 • Reference Beacon Operation: The MCC of a Ground Segment Provider that operates a Cospas-Sarsat reference beacon is responsible for the coordination and the reporting of all activities related to the operation of that beacon. • Reporting Requirements: An MCC is required to be able to retrieve and to report on the performance of the Cospas-Sarsat System, as required by document C/S A.005 (the MCC specification) and by document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”. 4.1.3 Location and Facilities Beyond the functional requirements listed above, there are no specific requirements for the location or facilities for an MCC. In summary, an MCC must be located in a place where there are facilities to support: • The personnel who operate the MCC, • The equipment used by the MCC, • The communications that are needed by the MCC, • The maintenance of the MCC. In practice, many MCCs are located in facilities that are shared with one or more of: • The offices of the agency that operates the MCC, • An associated RCC (or related search and rescue facility), • An associated LUT, • A reference beacon operated by the same administration, • A beacon simulator operated by the same administration. Although almost all MCCs share facilities with one or more of these, there is no requirement that the MCC facilities be shared with any other facility, or with any specific facility. In general, the choice of a location for an MCC is determined by the facilities available to the agency that will operate the MCC and by the access to the power and communications links that are necessary to the operation of the MCC. 4.1.4 Management and Personnel An MCC is defined in the Cospas-Sarsat documents as a functional entity, with no specific requirements for how it should be implemented. However, there is a strong implication that an MCC must be staffed: many of the functions that are required of an MCC can only be performed by (or under the supervision of) a human operator. 4-5 All operational MCCs are staffed by an MCC Manager (who may be called the Head of MCC, MCC Chief Operator, or some similar title) and a number of full-time operators. The operators perform the day-to-day functions that are necessary to keep the MCC operational, and the manager directs their performance and intervenes when necessary (possibly because of some unusual circumstance that may be beyond the capability of the operator). The MCC is the focus of the operations of the Cospas-Sarsat Programme for each participating Ground Segment Provider and for its declared Service Area. Each MCC is responsible for the establishment of procedures for the distribution of Cospas-Sarsat data within its Service Area. In effect, the MCC manages the Cospas-Sarsat operations for the Participant Administration and supports the other nations in its Service Area. This responsibility implies several operational requirements for the MCC and its personnel. These requirements are identified in section 5.1 of this Handbook. 4.1.5 MCC Equipment As noted above, there are no explicit requirements for specific equipment to be installed and used in a Cospas-Sarsat MCC. However, there are very few manufacturers of MCC equipment, and most MCCs include a computer system and communications equipment that is similar to those which are shown in Figure 4.3. The illustrations in the Figure show scenes at several typical Mission Control Centres. The maps, both the physical maps mounted on the walls and the software maps displayed on the computer terminals, are essential to the operation of an MCC, and provide a visual background for the incident alert data that is received and processed by the MCC. The equipment of an MCC includes the communications facilities that are used by that MCC. Although the equipment that links the MCC computers to the data communications network is installed in the MCC, this equipment and the actual network facilities may be leased from a commercial service provider. However, they remain an essential part of the MCC equipment. The equipment at an MCC must meet the availability requirements of C/S A.005: “The MCC shall be available to perform its functions 99.5% of the time over a period of one year.” This availability requirement applies to both the equipment in the MCC and the communications links that are used by the MCC. Separate - and usually more demanding - reliability requirements are set for each of the different communications links that an MCC may use. MCC operators, as shown in these illustrations, are an essential part of the MCC. While much of the MCC operation can be automated, there are some aspects that can only be performed by a human operator. 4-6 Figure 4.3: Typical MCC Images The operation of an MCC is illustrated by these images of typical MCCs that are currently operational in the Cospas-Sarsat System. When a new MCC is installed, or after any major change to the MCC equipment or software, the MCC must be commissioned before it can be operated in the Cospas-Sarsat Ground Segment. The details of the commissioning procedures and the tests that must be accomplished are described in document C/S A.006, “Cospas-Sarsat Mission Control Centre Commissioning Standard”. In addition to ensuring that the equipment is reliable, the MCC must make the arrangements necessary to provide a back-up capability in the event that the equipment fails. Backup for the communications services may be provided in a variety of different forms, ranging from alternate network connections to complete separate communications services. Regardless of the back-up facilities available at the MCC site, all MCCs prepare a plan to hand over responsibility for their Service Area to another MCC in the event that the equipment or services that are used at the operational MCC are not able to provide the necessary level of service. A description of the backup plans for each MCC is contained in section 5.3 of document C/S A.001, “Cospas-Sarsat Data Distribution Plan”. Unless these back-up arrangements are called upon operationally, they must be tested at least once a year. ![Image 1 from page 48](/images/cospas-sarsat/G-series/G010/G010_page_48_img_1.png) 4-7 4.1.6 Automatic Operations Although there is no explicit requirement that a Cospas-Sarsat Mission Control Centre must include a computer system, every operational MCC is built around an automated computer system that performs the bulk of the work required to implement document C/S A.001, “Cospas-Sarsat Data Distribution Plan” (the DDP), and to format and transmit or to receive and process the messages that are defined in document C/S A.002, “Cospas-Sarsat Standard Interface Description”, (the SID). The illustrations above provide a general outline of the structure of the hardware that is required to automate a Cospas-Sarsat MCC. The software that is run on this MCC computer system includes a variety of components to perform the different functions that are required of the MCC; Table 4-1 contains a list of the software components that are most commonly implemented in a functional MCC. Table 4-1 – MCC Software Structure This is a sample list, with descriptions, of the components that might be included in a typical MCC software package. Title Function Comments OS Operating system Normally a commercial product, sold by the manufacturer of the computer system Manager Software to manage and control the other components of the MCC application software package Custom MCC software; usually designed and built by the MCC manufacturer. Comms Input Manage the communications receiving software May be a combination of a commercial software communications package and custom MCC software. Input Processing Interpret and validate the messages received from the associated LUTs or from other MCCs. Custom MCC software Beacon Message Processing Extract and validate the beacon message data from the input messages Custom MCC software Location Processing Process the position data (encoded location or independent location) from the incident alert message Perform GEOSORT to determine which SRR contains the alert location Custom MCC software 4-8 Title Function Comments Routing Determine the appropriate destination for the incident alert message Custom MCC software Formatting Generate the SIT message(s) for onward transmission of the incident alert data Custom MCC software Comms Output Manage the communications transmission software May be a combination of a commercial software communications package and custom MCC software. Archival Manage the storage and retrieval of the data that is processed by the MCC computer system Custom MCC software Operator Display Generate data displays for the MCC operator In most MCC systems, this includes a geographic map display, as well as text displays of the data that is processed through the MCC computer system Custom MCC software Operator Interface Accept and process commands from the MCC operator Custom MCC software Although a few MCCs have designed and developed their own hardware configurations and software implementations, the majority of MCCs have purchased their automated systems from one of the small number of manufacturers of these systems. Representatives of these manufacturers (as members of the delegations of their customers, who are Participants in the Cospas-Sarsat Programme) often attend Cospas-Sarsat meetings that discuss and update data distribution specifications, as a means to help keep their products compliant with related Cospas-Sarsat requirements. It is then up to each Ground Segment Provider to make the contractual arrangements that are essential to ensure that the up-to-date versions of the hardware and software are installed and maintained in their own MCC. As the specifications and requirements for the Cospas-Sarsat data distribution system are amended, the Secretariat maintains a list of current modifications, and each Ground Segment Provider is expected to notify the Secretariat of their plans and schedules for the implementation of these changes in their own system, and then to notify the Secretariat when their MCC has been updated to become compliant with each new requirement. Depending on the nature of the new requirements, the upgraded MCC may have to be put through a partial (or complete) set of commissioning tests before it can be used operationally. Related information is provided in document C/S A.006 section “Recommissioning of a Previously Commissioned MCC”. 4-9 4.2 Processing LUT Data The Local User Terminal (LUT) is the ground station that receives data, through one or more of the satellites of the Cospas-Sarsat Space Segment, from an active distress beacon and processes that data to extract the beacon message and (if possible) determine an independent location estimate for the beacon. This is the basis of the incident alert data that is distributed through the MCC to the Search and Rescue authorities. A Ground Segment Provider that operates an MCC is not required to also operate a LUT. However, if an MCC has one or more associated LUTs, the MCC is responsible for the management and coordination of the LUT operations within the Cospas-Sarsat System. Each LUT may produce an independent location estimate for a beacon alert: • After each pass of a LEOSAR satellite over the beacon, a LEOLUT generates a Doppler location estimate for the beacon, if possible. A Doppler solution inherently contains two different positions. • After it receives a beacon burst through multiple different satellite channels, a MEOLUT generates a Difference of Arrival (DOA) location estimate for the position of the beacon, if possible. • Every LUT forwards the beacon message to the MCC with the solution data. This beacon message may contain an encoded position. This encoded position is the only beacon location estimate that is available from a GEOLUT. ANNEX C of this Handbook explains many of the concepts associated with the solution data that is generated by the Cospas-Sarsat LUTs and defines some of the terms that are used in the incident alert messages. 4.3 Cospas-Sarsat Data Distribution Plan Document C/S A.001, “Cospas-Sarsat Data Distribution Plan” (the DDP), contains a complete description of the requirements for the distribution of data through the network of MCCs that comprise the Cospas-Sarsat data distribution system. That document includes several tables that identify how each type of message is to be formatted and sent through the system. These tables are encoded into the computer systems that are run at each MCC, and the decisions and implementation of the DDP are almost completely automated. 4.3.1 MCC Service Area When each MCC is installed and commissioned into the Cospas-Sarsat System, a Service Area is declared by that MCC. In essence, this MCC Service Area identifies the region for which the MCC will be responsible, and within which the MCC will distribute incident alert data to RCCs and SPOCs. This area is usually delimited by the boundaries of the Search and Rescue Regions that it 4-10 will serve and identifies the countries that are expected to provide Search and Rescue support within those regions. The details of the procedures for the assignment of the Service Area of an MCC are described in section 5.2.2.3 ("MCC Service Areas") of document C/S P.011, “Cospas- Sarsat Programme Management Policy”. The following sections contain a brief description of the data distribution system; for a more detailed explanation of the individual parts of this system, refer to ANNEX A in this Handbook. Because the location data that are provided with a distress incident alert are only estimates of position, there is some uncertainty in the location of the distress incident. While document C/S A.005 only requires that SAR boundaries be implemented in an MCC within a 25 km tolerance, some MCCs employ buffer SRRs, to ensure that alerts with a location near a SRR boundary are distributed to all responsible SAR authorities. Except for Ship Security Alerting System (SSAS) beacon alerts, an MCC is responsible for the delivery of any alert message with the position in its service area to the SPOC or national RCC that is responsible for the Search and Rescue Region (SRR) that contains the alert message position. An MCC delivers alert messages for SSAS beacon for States in its service area to the competent authority, as designated by the State identified by the country code in the beacon message, regardless of beacon location. For an alert for which the responsible authority is not in its service area, the MCC delivers the alert to the appropriate MCC via the nodal MCC network. 4.3.2 DDRs and Nodal MCCs A nodal MCC is a complete operational MCC, which is expected to have all the capabilities of any MCC. In addition, a nodal MCC is required to support additional capabilities, which are described in Chapter 6 of the document C/S A.005. As described in document C/S P.011, “Cospas-Sarsat Programme Management Policy”, “a nodal MCC shall coordinate with and act as a focal point for MCCs in its DDR [Data Distribution Region] on Cospas-Sarsat System matters and provide support and assistance to developing MCCs within its DDR.” As indicated in Table 4-2 and illustrated in Figure 4.4, the Cospas-Sarsat data distribution system in 2023 is divided into six DDRs, with six nodal MCCs. Table 4-2 – Data Distribution Regions This list identifies each of the existing Data Distribution Regions and the associated nodal MCC. 4-11 DDR Data Distribution Region Nodal MCC Ground Segment operator CDDR Central Data Distribution Region FMCC France EDDR Eastern Data Distribution Region CMC Russia SCDDR South Central Data Distribution Region SPMCC Spain SPDDR South Pacific Data Distribution Region AUMCC Australia NWPDDR North West Pacific Data Distribution Region JAMCC Japan WDDR Western Data Distribution Region USMCC USA Figure 4.4: Cospas-Sarsat Data Distribution Network This illustration shows the nodal MCCs and the links that connect the different DDRs of the Cospas- Sarsat Ground Segment. The decision of which MCCs will be supported by each nodal MCC is made by the Cospas-Sarsat Council, based on the mutual agreement of the nodal MCCs and the MCCs that will be supported by the nodal MCC. The boundaries of the DDR are implicit in the GEOSORT: they are the outer boundaries of the Service Areas of all of the MCCs that comprise the DDR. Each MCC must be capable of distributing the incident alert data for any position within its own Service Area. For a position that is not in its own Service Area, the MCC (if it is not a nodal MCC) ![Image 1 from page 53](/images/cospas-sarsat/G-series/G010/G010_page_53_img_1.png) 4-12 sends the incident alert data to its nodal MCC. The nodal MCC must then determine whether the position is inside its DDR or not: • If the position is in the DDR, the nodal MCC will send it to the MCC that is responsible for the Service Area in which the position is located. • If the position is not within its own DDR, the nodal MCC will send the incident alert message to the nodal MCC that is responsible for the DDR in which the position is located. This procedure minimizes the amount of information that is required to be held in each MCC: • Any MCC that is not a nodal MCC only has to know the boundaries of the SRR of each RCC or SPOC within its own Service Area. • In addition, each nodal MCC must have: - within its own DDR: ▪ the boundaries of every MCC Service Area, ▪ the identification and address of the associated MCC, - for the rest of the world: ▪ the boundaries of every DDR, ▪ the identification and address of the associated nodal MCC. At the same time, the structure is sufficient to ensure that the incident alert data will always be sent to the correct MCC for processing and for eventual distribution to the correct responsible SAR authority. It should, however, be noted that the Central Data Distribution Region (CDDR) has implemented a mesh configuration: • If the position is in the CDDR, the MCC sends the alert directly to the MCC that is responsible for the Service Area in which the position is located. • If the position is not within the CDDR, the MCC message is forwarded to the nodal French MCC, which routes the message to the nodal MCC responsible for the DDR in which position is located. This is an exception to the general rule, which was adopted by mutual agreement among the Ground Segment Providers in the CDDR. 4.3.3 RCCs, SPOCs and Search and Rescue Regions The international agreements on Search and Rescue, as defined in the Safety of Life at Sea (SOLAS) Convention of IMO and in the Chicago Convention of ICAO, define the responsibilities of the participating States and of the Rescue Coordination Centres (RCCs) that they operate to perform the activities that are necessary to support Search and Rescue. Each State must identify 4-13 its Search and Rescue Regions (SRRs); that is, the geographical area that is supported by each of its RCCs. An MCC's Service Area is that part of the world within which a Cospas-Sarsat alert data distribution service is provided by that MCC, in accordance with document C/S P.011, “Cospas- Sarsat Programme Management Policy”. When an MCC is commissioned into the Cospas-Sarsat System, it is required to declare its Service Area; that is, to identify the list of RCCs and SPOCs to which that MCC will distribute Cospas-Sarsat alert data. The list of countries / regions included in the Service Area of each MCC is provided at section 5.3 (Description of Cospas-Sarsat MCCs) of document C/S A.001 (the DDP). Document C/S P.011, “Cospas-Sarsat Programme Management Policy”, sets out the policy considerations for the establishment of MCC Service Areas. It is expected that each MCC Service Area and its boundaries will be consistent with the areas of national responsibility established by the International Civil Aviation Organization (ICAO) and the International Maritime Organization (IMO), and that they will be decided by mutual agreement among all Participants. When it is impossible to achieve agreement among all the Participants, Cospas-Sarsat will accept that a new Service Area may overlap with one or more existing MCC Service Areas. In this case, any alert in the region of overlap will be sent to the MCC or SPOC associated with both of the agreed MCC Service Areas. The guidelines for the establishment of a new MCC in the Cospas-Sarsat Ground Segment are set out in Annex A of document C/S A.006, “Cospas-Sarsat Mission Control Centre Commissioning Standard”. The Ground Segment Provider is expected to identify its proposed Service Area, and to provide a set of boundary points for this new MCC Service Area. The proposed Service Area will be reviewed by the Joint Committee and recommended (as amended, if necessary) to Council for approval. The Cospas-Sarsat Secretariat will then add these boundary points to the GEOSORT and make the updated GEOSORT available to all MCCs. The new MCC must identify each of the RCCs in its declared Service Area and determine which communication services will be used to communicate with that RCC. • For an RCC that is operated by a foreign country, the details must be defined in cooperation with the government of that country. The foreign RCC is known as a Search and Rescue Point of Contact (SPOC). Communications between the MCC and its SPOCs are established in accordance with document C/S A.005 sections entitled “Data Communication Links” and “Data Formats”. • For an RCC that is operated by the government of the country that is the Ground Segment Provider for the MCC, then the communications between the MCC and the RCC are an internal matter, subject to the prerogatives of national sovereignty. However, in fact, most of the operational MCCs operate their internal communications links to their RCCs using communications services and protocols that are very similar to the links defined for a foreign SPOC. 4-14 Document C/S A.005 recommends that the MCC establish appropriate arrangements with all the Administrations and their SPOCs in its Service Area on communication networks to be used for the distribution of alert data. If a suitable arrangement cannot be agreed, the MCC is directed to send the incident alert data to one of its own RCCs and ask that RCC to follow its own SAR procedures to deal with the incident. These RCC procedures may include provisions to pass the information to an RCC in the destination country that will then prosecute the incident. Document C/S A.005 requires that each MCC should maintain at least two separate data communications links with every SPOC or RCC with which it communicates. This ensures that there is a reliable backup communications link available, in case the primary link fails. This document also requires that a link “shall be available for at least 95% of the time during each calendar day”. As each new SPOC is identified, either through agreements with Cospas-Sarsat or via other channels, it will be incorporated into an existing MCC Service Area by mutual consent of the SPOC national authority and the appropriate MCCs. It is strongly recommended (although not mandatory) that an MCC should formalize this agreement with a written MCC-SPOC Agreement; a model agreement is available on the Cospas-Sarsat website under the tab: select “Templates and Forms” and then “MCC/SPOC Model Agreement Template”. This agreement should include a description of any unique arrangements for a particular MCC-SPOC communications link. All MCCs should be notified when a new SPOC is identified by an MCC. The reliability of the communication links between an MCC and its supported RCCs (and, especially, its supported SPOCs) may vary widely, depending on the facilities that are available in each part of the world. Because of problems that have arisen with some SPOCs in the past, all MCCs are expected to verify these communications links on a regular basis: • If the communications links are used operationally (in support of actual Search and Rescue activities), then the MCC should verify that the operational messages are consistently received and acted upon as required. • If there is not much operational activity, then the MCC should send a test message, and request an active confirmation that the message has been received at the RCC, to each SPOC at least once a month. This requirement is stated in section 3.1.4.3 ("MCC to RCC/SPOC Communication Links") of document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”. The results of the SPOC communications tests are reported by each MCC to the Cospas-Sarsat Secretariat, on a monthly basis. The Secretariat summarizes these reports in its annual Report on System Status and Operations, which is presented to the Cospas-Sarsat Joint Committee for review at each annual meeting. This data is also presented to the IMO Sub-Committee on Navigation, Communications and Search and Rescue (NCSR) as part of the annual Cospas-Sarsat status report. If an MCC finds that it has difficulty getting a message correctly received at one of its supported SPOCs, then it should communicate with the SPOC and with the national authority that operates 4-15 the SPOC to ensure that any problems are corrected. If necessary, the international organizations (such as ICAO) may offer some support to the nation that operates the SPOC to ensure that suitable facilities are available to it. 4.3.4 Alert Data Distribution The procedures for the distribution of incident alert data are described in document C/S A.001, “Cospas-Sarsat Data Distribution Plan”. In particular, the rules for the distribution of incident alert data are set out in a series of tables (called “Processing Matrices”) in section 4 (“Operational Procedures for Cospas-Sarsat MCCs”) of that document. There is a different table for each set of conditions under which the message must be distributed. These processing matrices describe the actions to be taken in various circumstances, as defined by the inputs available with each incident alert. The inputs and actions are defined in C/S A.001: Table 4-9 (Definition of the Input, Status and Action Words for 406 MHz Alerts), which is contained in section 4.2.5.2 (“Definition of Input, Status and Action Words”). The distribution procedures for incident alert messages are explained further in ANNEX A of this Handbook. Characteristics of LEOSAR, GEOSAR, and MEOSAR Alerts A Cospas-Sarsat incident alert is a report of the detection and location of a distress beacon by the Cospas-Sarsat System. While all alerts share a lot of common characteristics, there are a few features that are unique to each of the Cospas-Sarsat detection and processing systems: • The LEOSAR system provides a dual position estimate for each beacon, with one position on each side of the satellite orbit plane. A second (independent) position estimate is required to resolve the ambiguity between the two position estimates. The delay between the activation of a beacon and the distribution of a confirmed location estimate to an RCC may be anywhere between a few minutes and eight hours. • The MEOSAR system typically provides a position estimate within a few minutes of beacon activation. • The GEOSAR system typically provides detection within a few minutes of beacon activation. However, it does not provide any independent position estimate. All three systems relay the beacon message; if there is an encoded position in that beacon message, that location data will be available in the incident alert that is generated by the Cospas-Sarsat System. ANNEX C of this Handbook contains descriptions of the data that may be included in an incident alert message derived from each of these sources. The specifications for the message formats and the message data fields that are used to transmit the alert message data are discussed in more detail in ANNEX B of this Handbook. ![Image 1 from page 57](/images/cospas-sarsat/G-series/G010/G010_page_57_img_1.png) 4-16 Matching of Beacon Alerts As each beacon alert is received at an MCC, the data in the alert message is compared to alerts that have been received previously by the MCC to determine if this alert is a new beacon activation or if it is an update for an existing beacon activation. (Note that only recent alerts are checked; any alert that is more than twenty-four hours old will have aged out and will not be considered in this check.) The beacon identifier, which is a subset of the beacon message, is used to identify all previously received alerts for the same beacon. Special rules are used to match the beacon identifier when the beacon message contains invalid or inconsistent data. See document C/S A.001 section entitled “406 MHz Beacon Message Validation” for more information. The specifications for the matching of alert data are contained in document C/S A.001, in the processing matrix in Table 4-1 (“MCC Data Routing Matrix”) and in the accompanying text in section 4.1.5 (“Inter-MCC Routing of Alert Data”) of that document. These specifications are discussed in more detail in section A.4.3 of this Handbook. Document C/S A.002 contains the specifications for the message formats that are used to transmit the alert data; these formats are discussed in more detail in section B.5 of this Handbook. Unlocated Alerts In some cases, an incident alert will not include any location data. This may happen if: • The beacon message did not include an encoded location, because: - The beacon did not have encoded location capability, - The beacon did not receive enough data to compute an encoded location, - The beacon message was determined not to be a valid message. • The LUT did not receive enough data from the beacon to compute an independent location: - A LEOLUT requires at least three data measurements to compute a Doppler position estimate, - A MEOLUT requires data received through at least two different satellites, with sufficient spatial separation, to compute a DOA position estimate, - A GEOLUT is not, because of the nature of a geostationary orbit, capable of computing an independent position estimate. For a given alert, if the beacon message did not include encoded location and the LUT did not compute an independent location, the incident is an unlocated alert, and the incident alert data cannot be distributed on the basis of the location. If the beacon message for an unlocated alert is valid (as defined in the appropriate beacon specifications document), then the country code in the message is used to determine the destination ![Image 1 from page 58](/images/cospas-sarsat/G-series/G010/G010_page_58_img_1.png) ![Image 2 from page 58](/images/cospas-sarsat/G-series/G010/G010_page_58_img_2.png) 4-17 of the incident alert message. Otherwise, the information in the alert is not reliable or useful, and no incident alert message is reported. The specifications for processing unlocated alerts are contained in document C/S A.001, in the first column of the processing matrix in Table 4-10 (“Processing Matrix, Message Formats and Distribution of New 406 MHz LEOSAR/GEOSAR Alerts”) or Table 4-11 (“Processing Matrix, Message Formats and Distribution of New 406 MHz MEOSAR Alerts”), and in the accompanying text in section 4.2.5.3.1 (“Processing Before Position Confirmation”) of that document. These specifications are discussed in more detail in section A.3 of this Handbook. Document C/S A.002 contains the specifications for the message formats that are used to transmit the unlocated alert data; these formats are discussed in more detail in section B.5.1 of this Handbook. Confirmation of Beacon Positions The beacon position provided in an incident alert that has been received from only one independent source is unconfirmed and may not be reliable. A second position, which matches the original position within 20 km, for the same beacon must be received from an independent source before the beacon position can be considered confirmed. Two sources of data for the position of a beacon are considered to be independent as follows: • an encoded location and a MEOSAR DOA location, • an encoded location and a LEOSAR Doppler location, • two MEOSAR DOA locations computed from data received through different sets of satellites (i.e., each satellite set has at least one unique satellite) and different beacon transmissions (i.e., there is at least a 2-second time separation in some portion of the time period associated with each DOA position) or the last detect time for the two DOA alerts differs by at least 30 minutes, • a MEOSAR DOA location and a LEOSAR Doppler location, • two LEOSAR alerts containing Doppler locations that have been computed from data collected on different satellite passes over the beacon. On the other hand, the following pairs of alerts would not be considered independent: • two encoded locations (even if they were received through different spacecraft or different LUTs, since the source of the data is in the beacon), • two LEOSAR alerts containing Doppler locations that have been computed from the same satellite pass over the beacon, • two LEOSAR alerts containing Doppler locations that have been computed from passes of different satellites over the beacon, if the two satellites are in the same (or almost the same) orbital plane, where each Doppler position in one alert matches a Doppler position in the other alert within 20 km, ![Image 1 from page 59](/images/cospas-sarsat/G-series/G010/G010_page_59_img_1.png) 4-18 • two MEOSAR DOA locations computed from data received through the same set of satellites, with last detect times within 30 minutes of one another. As explained in the following paragraphs, the processing of the new alert will vary, depending on whether or not this is a confirmed position alert. As explained in section C.1.2 of this Handbook, the LEOSAR Doppler processing generates a solution with two different position estimates, on different sides of the satellite orbit plane, and it also provides an estimate of the relative probability that each position identifies the correct location. Normally, for each incident, one of these positions will be close to the correct beacon location, and the other solution will be the image (the correct location reflected in the orbit plane of the satellite). Since the probability computed by the LEOLUT is not a sure indication of the image solution, the MCC must wait until the solution can be confirmed by an independent position estimate before it can resolve the ambiguity of these two solutions. The ambiguity resolution process is described in section C.1.2.1 of this Handbook. Document C/S A.002 contains the specifications for the message formats that are used to transmit the alert data; these formats are discussed in more detail in ANNEX B of this Handbook. The specifications for the message formats that are used to transmit alert data with an unconfirmed position are described in section B.5.5 of this Handbook. The specifications for the message formats that are used to transmit alert data with a confirmed position are described in section B.5.6 of this Handbook. Special Alert Processing There are some cases where special processing is required to determine when and where the incident alert message should be sent. These special cases are addressed in ANNEX A of this Handbook, in the sections listed in Table 4-3. Table 4-3 – Special Processing This table identifies the circumstances that require special processing, and points to the sections in ANNEX A of this Handbook that describe the processing that is done in each circumstance. Special Circumstance Processing Reference Ship Security Alerting System (SSAS) beacon A.4.7.1 Notification of Country of Registry (NOCR) A.4.7.5 Return Link Service (RLS) beacon A.4.7.2 Distress Tracking ELT – ELT(DT) A.4.7.3 System Beacon A.4.7.4 Cancellation Message A.4.7.5 ![Image 1 from page 60](/images/cospas-sarsat/G-series/G010/G010_page_60_img_1.png) 4-19 4.3.5 System Data Distribution System Data is the information that is required by the various components of the Cospas-Sarsat Ground Segment to ensure that they will be able to perform the functions that are required of them. System Data messages include the narrative messages that are used to send status and other information between MCCs. Table 8 contains a summary of the System data and of the SIT message formats and data fields that are used for the distribution of System data. System data message formats are described in more detail in ANNEX B section B.6, and in the tables that are included in that Annex. Table 4-4 – System Data This table summarizes the system message formats and the message data fields that are specific to these System Messages. System Data SIT Message Numbers Satellite orbital data 215, 216, 217 SARR & SARP Calibration 415, 417, 510 SARP Telemetry 416, 425, 435, 445 SARR Teemetry 515, 525, 535, 545 Status and narrative 605, 915 Beacon registration 925, 926, 927 Each MCC normally maintains orbital data for each operational LEOSAR, GEOSAR and MEOSAR satellite and calibration data for each operational LEOSAR satellite. This data is distributed through the MCC network by the MCC of the Space Segment Provider that is responsible for that part of the Cospas-Sarsat Space Segment. The MCC is required to use orbital data for LEOSAR, GEOSAR and MEOSAR satellites to validate whether position data provided in alert messages is within the footprint of associated satellites at the time the beacon was detected. The MCC is required to ensure that its associated LEOLUTs have up-to-date orbital and SARP calibration data for all operational LEOSAR satellites. When an MCC receives a System Data Message that contains satellite orbit or calibration data, it must validate the data (by comparing it with the data it already has). If the new data is within an acceptable tolerance of the old data, then the MCC should use the new data. If the new data is out of tolerance from the old data, then the MCC operator should be notified. The specifications for the processing of system data messages are contained in document C/S A.001, in the routing matrix in Table 4-1 (MCC Data Routing Matrix), in the processing matrix in Table 4-2 (System Information Distribution), and in the accompanying text in section 4.1.6 (Inter-MCC Routing of System Information). These specifications are discussed in 4-20 more detail in section A.7 of this Handbook. The specifications for the message formats that are used to transmit the system data are discussed in more detail in sections B.6 and B.7 of this Handbook. Where the text in ANNEX A indicates that the System Data is to be forwarded to the associated LUTs, this only applies if the MCC has one or more associated LUTs of the indicated type. Narrative Messages A narrative message is a free-format message that is used to communicate between MCC operators. Although some narrative messages may be generated automatically by the software of an MCC computer system, many narrative messages are typed in by the MCC operator and sent on request of the operator. These narrative messages may serve a variety of purposes, including (for example): • Request for re-transmission of a message that was not correctly received at the MCC, • Inquiries about problems with the processing or communications from another MCC, • Request for additional information about an alert or System data message, • Notification of planned tests or other (non-distress) beacon activation. The specifications for the processing of narrative messages are discussed in more detail in section A.7.5 of this Handbook. Document C/S A.002 contains the specifications for the message formats that are used to transmit a narrative message; these formats are discussed in more detail in section B.7 of this Handbook. There are samples of narrative messages in Chapter 6 and in ANNEX B of this Handbook. System Status A system status (SIT 605) message is a narrative message that is transmitted to all MCCs to indicate changes in System status and to provide beacon test notification. System status messages include System element and System function failures, scheduled maintenance, integration or testing of new System elements, and the commissioning of new equipment or new capabilities of existing equipment. A system status message may be generated automatically by the MCC computer system or it may be generated manually by the MCC operator. The specifications for the processing of system status messages are discussed in more detail in section A.7.5 of this Handbook. Document C/S A.002 contains the specifications for the message formats that are used to transmit a system status message; these formats are discussed in more detail in section B.6.5 of this Handbook. There are samples of system status messages in Chapter 6 and in ANNEX B of this Handbook. ![Image 1 from page 62](/images/cospas-sarsat/G-series/G010/G010_page_62_img_1.png) ![Image 2 from page 62](/images/cospas-sarsat/G-series/G010/G010_page_62_img_2.png) 4-21 Satellite Orbit Data Orbit data for the LEOSAR and MEOSAR satellites is normally generated by the Space Segment Provider that is responsible for the satellite to which the data applies. This information is generated automatically for the MCC operated by that Space Segment Provider and is formatted and transmitted to all MCCs once a day. They are also transmitted as needed after every satellite manoeuvre. The format of this data normally depends on the Space Segment concerned: • The LEOSAR orbit data is normally sent as orbit position and velocity vectors in the SIT 215 or SIT 216 message format. • The MEOSAR orbit data is normally sent as Two-Line Elements (TLEs) in the SIT 217 message format. • The GEOSAR orbit data is not automatically distributed. The orbit data must be verified by the MCC when it is received, as discussed in section 4.3.5 of this Handbook. Once it has been validated, the orbit data may be used in the MCC to predict and/or schedule upcoming satellite passes should be transmitted to any associated LEOLUT as needed to ensure that the LEOLUT has accurate orbit data. The specifications for the processing of orbit data messages are discussed in more detail in sections A.7.2 to A.7.2.3 of this Handbook. Document C/S A.002 contains the specifications for the message formats that are used to transmit an orbit data message; these formats are discussed in more detail in ANNEX B section B.6.1 of this Handbook. System Calibration Data For various parts of the processing done in the Ground Segment of the Cospas-Sarsat System, some form of calibration data is required. While some of this data can be generated internally by the LUTs or MCCs that comprise the Ground Segment, this calibration data is normally generated by the Space Segment Provider that is responsible for the satellite to which the data applies. These messages are generated automatically for the MCC operated by that Space Segment Provider, and are transmitted at regular intervals, according to the needs of each satellite constellation: • the LEOSAR SARP time and frequency calibration data, • the LEOSAR SARR frequency calibration data. The system calibration data must be verified by the MCC when it is received, as discussed in section 4.3.5 of this Handbook. ![Image 1 from page 63](/images/cospas-sarsat/G-series/G010/G010_page_63_img_1.png) ![Image 2 from page 63](/images/cospas-sarsat/G-series/G010/G010_page_63_img_2.png) 4-22 Once it has been validated, the system calibration data should be stored in the MCC, and transmitted to any associated LEOLUT as needed to ensure that the LEOLUT has accurate calibration data. The specifications for the processing of system calibration data messages are discussed in more detail in section A.7.3 of this Handbook. Document C/S A.002 contains the specifications for the message formats that are used to transmit a calibration data message; these formats are discussed in more detail in sections B.6.2, B.6.3, and B.6.5 of this Handbook. Spacecraft Command and Control Data At times, it is necessary that the Space Segment Providers issue commands to manage their spacecraft systems, or that they receive status data from the spacecraft. These command and control messages are normally generated by the MCC operated by one Space Segment Provider and are sent to another Space Segment Provider. These messages are not normally of particular interest to any other MCC. The specifications for the processing of spacecraft command and control data messages are discussed in more detail in section A.7.4 of this Handbook. Document C/S A.002 contains the specifications for the message formats that are used to transmit a a spacecraft command and control data message; however, these formats are not discussed in any more detail in this Handbook. 4.4 Data Communication An essential part of the Cospas-Sarsat data distribution system is the ability to communicate the data from an MCC to its destination: either to the next MCC in the network or to the authority that is the final destination of the incident alert data. Because of the urgency of the information that is associated with a distress incident, most of these communications networks are automated. The specifications for the data communications networks are contained in the SID (document C/S A.002). Most of the data communications between MCCs and from MCCs to SPOCs are carried over commercial data communications networks. As the available technology changes, the networks that may be used by the Cospas- Sarsat data distribution system are updated to keep up with the technology. To ensure the quality and reliability of the communications that are used by the Cospas-Sarsat data distribution system, every MCC is required to maintain two separate communications links to support message exchange with other MCCs. Despite the fact that most of the communications at an MCC are automated and carried over data communications links, an MCC is also required to maintain voice communications capabilities. This is normally done over the Public Switched Telephone Network (PSTN); however, some MCCs also have radio communications capabilities as well. ![Image 1 from page 64](/images/cospas-sarsat/G-series/G010/G010_page_64_img_1.png) 4-23 In 2023, the data networks that are approved for use in the Cospas-Sarsat data distribution system are: • FTP/VPN, • AFTN/AMHS, • email (subject to restrictions, as described in section 4.4.1.3 of this Handbook). Document C/S A.002, “Cospas-Sarsat Standard Interface Description” (the SID), includes a set of Annexes that describe the protocols that should be used with the various communications networks that are considered suitable for use with the Cospas-Sarsat data distribution system. These Annexes are identified in Table 4-5. Table 4-5 – Network Annexes in the SID This table lists the networks that are described in the Annexes of the SID (document C/S A.002) • Annex E & F Internet File Transfer Protocol (FTP) over a Virtual Private Network (VPN) • Annex G Aeronautical Fixed Telecommunications Network (AFTN) and Aeronautical Message Handling System (AMHS)2 • Annex I Electronic Mail (email) over the Internet The SID also includes an Annex H, which is an “Implementation Plan for New Communication Links”. The document C/S A.005, “Cospas-Sarsat Mission Control Centre Performance Specification and Design Guidelines” contains some guidance about the communications link to be used for each of the facilities with which an MCC may communicate. In general, the communications links between MCCs, and between an MCC and the SPOCs that it supports, should be one of the networks that are described in the SID. However, any MCC and/or SPOC may come to a mutual agreement to use other communications facilities. The communications between an MCC and its associated national LUTs or RCCs may be determined by the national Administration, as a matter of national prerogative. Document C/S A.002 explicitly requires that each of the communications links that is operated by an MCC should be independent; that is, each link shall meet the specified requirements regardless of the traffic on any other link. Each of these networks is discussed briefly in section 4.4.1 of this Handbook. However, it is noted that communications network technology is a very technical field, and the user is referred to the 2 The AMHS network is being developed by the International Civil Aviation Organization (ICAO) as a replacement for the AFTN. The plan is for the new AMHS network to be compatible with the existing AFTN, so the transition from AFTN to AMHS is not expected to cause any significant issues for the Cospas-Sarsat data distribution system. Each MCC may move from AFTN to AMHS as the network facilities become available to it. 4-24 specifications in the Annexes to the SID for the detailed information that is necessary for the specification, procurement, management, and maintenance of the data communications networks at an MCC. The next section provides some of the unique requirements for each of the communications links supported by an MCC. 4.4.1 Communication Links FTP/VPN The most widely used form of data communications between Cospas-Sarsat MCCs is the File Transfer Protocol (FTP) over a Virtual Private Network (VPN) on the Internet (FTP/VPN). In 2023, the Internet is available almost everywhere in the world, and provides an available and reliable communications capability for the Cospas-Sarsat data distribution network. The use of a Virtual Private Network ensures the security of the communications for the alert and system data messages that are used by the MCCs of the Cospas-Sarsat Ground Segment. The information that is necessary to configure the FTP/VPN communications nodes to operate in the Cospas-Sarsat data distribution network is provided in the Annexes to C/S A.002, as listed in Table 4-5. AFTN/AMHS The Aeronautical Fixed Telecommunications Network (AFTN) is operated by ICAO for the use of Air Traffic Management Services; it has been made available to Cospas-Sarsat for the distribution of distress messages between MCCs and from MCCs to RCCs. As of 2023, ICAO is in the process of upgrading their communications services to the Aeronautical Message Handling System (more precisely, the ATS Message Handling System for air traffic control) (AMHS). The two systems are forward compatible, so individual MCCs or RCCs can convert from AFTN to AMHS without affecting their capability to operate in the Cospas-Sarsat data distribution network. AFTN and AMHS are text data message systems that are restricted to the used of authorized terminal operators; most of these operators are components of the international air traffic control services. The limited access that is provided by this restricted set of connections to the network assures the security of the data communications, as is necessary for the alert and system data messages that are used by the MCCs of the Cospas-Sarsat Ground Segment. The information that is necessary to configure the AFTN or AMHS communications node at an MCC to operate in the Cospas-Sarsat data distribution network is provided in the Annex to C/S A.002, as listed in Table 4-5. ![Image 1 from page 66](/images/cospas-sarsat/G-series/G010/G010_page_66_img_1.png) ![Image 2 from page 66](/images/cospas-sarsat/G-series/G010/G010_page_66_img_2.png) 4-25 Email As noted above, the Internet is available almost everywhere in the world, and provides an available and reliable communications capability for the Cospas-Sarsat data distribution network. The most common implementation of this capability is the transmission of email messages around the world. While this capability can be of use to the Cospas-Sarsat MCCs, it is not recommended for the data distribution system. The primary reasons that email is not recommended for use in the Cospas-Sarsat data distribution network are: • Security Emails that are sent over the Internet are not secure. Messages can be captured, read, and redirected without the approval (or even the knowledge) of the originator of the message. Addresses can be spoofed – that is, a message can be sent from one system as if it originated from a different system. Because it is so widespread, the Internet email system has been the subject of many attacks on the privacy and reliability of the messages that it carries. • Reliability The email servers that carry messages over the Internet do not provide any guarantee that a message will be sent to the intended destination, nor do they provide any guaranteed method to notify the origin or destination when a message is not sent. For the life-critical data that is sent through the Cospas-Sarsat data distribution system, this is not acceptable. Despite these limitations, when other services are not available, the use of email does provide an alternate capability for an MCC to communicate the alert and system data messages that are used by the MCCs of the Cospas-Sarsat Ground Segment. The information that is necessary to configure an email communications node to operate in the Cospas-Sarsat data distribution network is provided in the Annex to C/S A.002, as listed in Table 4-5. Fax Facsimile services are another form of data communications that is available almost everywhere in the world, and it also provides an available and reliable communications capability that could be used in the Cospas-Sarsat data distribution network. However, it is not recommended for use between MCCs in the data distribution system. The primary reason that fax is not recommended for use in the Cospas-Sarsat data distribution network is that the data that is received through a fax message is not readily amenable to automated processing. The message can easily be presented to a human operator, but it cannot easily be decoded and read (and processed) by a computer. For this reason, the use of fax in the Cospas- Sarsat data distribution network is normally limited to the transmission of incident alert messages to a SPOC or an RCC, where the message can be read and understood by a human operator. ![Image 1 from page 67](/images/cospas-sarsat/G-series/G010/G010_page_67_img_1.png) ![Image 2 from page 67](/images/cospas-sarsat/G-series/G010/G010_page_67_img_2.png) 4-26 Messages to be transmitted by fax may be sent automatically from the MCC or may need to be printed, prior to manual transmission, depending on the MCC fax capability. There are no directions in C/S A.002 for the configuration or use of a fax communications node to operate with the Cospas-Sarsat data distribution network. 4.4.2 Interfaces Each MCC supports several different communications interfaces. The specifications for the communications services used by an MCC are in document C/S A.005, “Cospas-Sarsat Mission Control Centre Performance Specification and Design Guidelines”. The general requirements are identified in section 3.4 of that document and the performance requirements for each type of link are described in section 5.2 of that document. The following sections describe some of the specific requirements for each of the different communications links that an MCC may use. For some of the communications links, the requirements are fairly definitely specified. However, the internal links within any one nation are subject to national prerogatives and are not explicitly specified by Cospas-Sarsat. Despite that, most of the internal links follow protocols and procedures that are very similar (if not identical) to those that are specified for the international communications. The Annexes to document C/S A.002 contain the specifications for the selection and configuration of the communications links that are used by an MCC for communications services. These specifications are generally followed by almost all MCCs; however, there are a few cases where some of the details of the required processing are adjusted to meet the requirements of a bilateral agreement between neighbouring MCCs. Note that, although an MCC may be required to support multiple communications links, the MCC specification explicitly states (in section 3.4.11 of C/S A.005) that “MCC data communication shall be implemented such that all communication links and networks can operate simultaneously without loss of information.” The MCC specification (in C/S A.005) does not explicitly require any specific communications checks or verification procedures, but it does state (in section 5.2 of C/S A.005) that “MCCs shall implement procedures (e.g., Positive Delivery Notification, Channel Checks, Automatic Resends, Checksums and Sequential Message Numbers) as needed, to ensure that the performance requirements in section 5 of this document are met.” MCC – MCC The primary communications links in the data distribution system join each MCC to one or more other MCCs. These links are required to be compliant with the communications requirements described in the Annexes to the SID. ![Image 1 from page 68](/images/cospas-sarsat/G-series/G010/G010_page_68_img_1.png) 4-27 The MCC specification requires that each MCC should maintain at least two separate data communications links with every MCC with which it communicates. This ensures a reliable backup communications link is available, in case the primary link fails. Although the SID allows the use of three different communications services, almost all MCCs use FTP/VPN as their primary link to other MCCs and use AFTN/AMHS as their backup link. In a very few cases, where the available AFTN service may not be reliable, email is used as the backup. The MCC specification (document C/S A.005, section 5.2.2) requires that the MCC to MCC links should be capable of transferring data to another MCC “within 10 minutes 99% of the time”, with less than 0.1% of the data lost or corrupted. The MCC must have an operable communications link to another MCC “for at least 99% of the time during each calendar day”. MCC – LUT The selection of the communications link between an MCC and its associated LUTs is a matter of national prerogative. The only specification imposed by Cospas-Sarsat is that the LUT must provide the MCC with all the information that it requires to satisfy the MCC specification (document C/S A.005). In fact, many MCCs use some variations on the incident alert message formats and protocols to communicate with their LUTs. However, in cases where the MCC and its associated LUT(s) are produced by the same manufacturer, internal file structures are often used for the exchange of data between the MCC and its associated LUTs. The MCC specification (document C/S A.005, section 5.2.1) requires that the MCC shall receive “all distress alert data transmitted by a LUT within 10 minutes from the completion of LUT processing 99% of the time” and “all distress tracking alert data by a LUT within 2 minutes from the completion of LUT processing 99% of the time”. In both cases, less than 0.1% of the data may be lost in transit. MCC – RCC/SPOC The MCC specification defines the communications between an MCC and its SPOCs. However, the selection of the communications link between an MCC and its associated RCCs is a matter of national prerogative. In fact, most MCCs use the incident alert message formats and protocols that are specified for communications with SPOCs to communicate with their associated RCCs. Although it may not be required, this simplifies the arrangements for backups when one MCC fails and has to be supported by another MCC. As a recipient of Cospas-Sarsat distress alert data, a SPOC is responsible to: • conduct SAR actions for any real alert (i.e., distress beacon activation) that is reported to it by the MCC, • share information about the results of each beacon activation with its associated MCC, ![Image 1 from page 69](/images/cospas-sarsat/G-series/G010/G010_page_69_img_1.png) ![Image 2 from page 69](/images/cospas-sarsat/G-series/G010/G010_page_69_img_2.png) 4-28 • respond to communications tests performed by the MCC by acknowledging receipt of each test message. MCC - RLSP The MCC specification states that the communications link between an MCC and its associated Return Link Service Provider (RLSP) is to be determined by mutual agreement between the MCC and the RLSP. (Note that this only affects an MCC that is supporting the Return Link Service of a GNSS provider.) The Return Link Service (RLS) is addressed in section A.4.7.2 of this Handbook. 4.4.2.4.1 MCC to Galileo RLSP through FMCC At the present time, the only operational Return Link Service Provider is the European Commission (EC), who operate the Galileo GNSS, and who have arranged for the support of the RLSP through the French MCC (FMCC) system. When an alert with a confirmed position is received from a Galileo RLS-capable beacon, the responsible MCCs (i.e., each MCC with the confirmed position in its Service Area and any associated nodal MCC) must forward that alert to the FMCC via the nodal MCC network. The FMCC will forward this information to the Galileo RLSP. Using the beacon identification and position information, the Galileo RLSP then determines the information necessary to send the acknowledgement message to the beacon: • the Galileo satellites that will see the beacon, • the times when the beacon will be visible to those satellites, • the identifier of the beacon to which the acknowledgement message should be sent. With this information, the RLSP can schedule the appropriate downlink transmission to the beacon. MCC - SSAS Competent Authority Document C/S A.005 states that the communications link between an MCC and its designated SSAS Competent Authority is to be determined by mutual agreement between the MCC and each SSAS Competent Authority. (Note that this affects every MCC that is associated with an SSAS Competent Authority and their backup MCC.) The SSAS contact details for ship security competent authorities are made available by IMO Member States in the IMO Global Integrated Shipping Information System (GISIS) database at https://gisis.imo.org/Public/Default.aspx. The Maritime Security button, after appropriate login, provides access to “Proper recipients of SSAS alerts”. Document C/S A.001, section 4.2.8 requires that “All States wishing to use the Cospas-Sarsat System to relay ship security alerts should make the necessary arrangements with their associated MCC. Arrangements should include the identification of the competent authority responsible for receiving the ship security alert and the communication link to the competent authority”. ![Image 1 from page 70](/images/cospas-sarsat/G-series/G010/G010_page_70_img_1.png) ![Image 2 from page 70](/images/cospas-sarsat/G-series/G010/G010_page_70_img_2.png) 4-29 The availability of SSAS contacts through IMO GISIS does not prevent MCC for routing SSAS data as described in document C/S A.001. Figure 4.5: IMO GISIS Maritime Security Website Interface This illustration shows the interface to be used to find the contact details for SSAS Authorities. MCC - ICAO Location of Aircraft in Distress Repository (LADR) Nodal MCCs provide ELT(DT) alert data to the Location of an Aircraft in Distress Repository (LADR) using Web Services, as described in document C/S A.002 section entitled “Web Service Communications”. As of mid-2023, details of this interface are still under development. Operational use of ELT(DT)s started on 1 January 2023, and the LADR is expected to be in operation by the end of 2023 or in early-2024. 4.5 SIT Messages The formats of the messages that are transmitted between MCCs in the Cospas-Sarsat Ground Segment are defined in the SID. Each of the messages exchanged by MCCs is identified by a Subject Indicator Type (SIT) number, which is included in the message. This SIT number is used by both the sending and the receiving computer system. 4.5.1 Introduction Each SIT number designates a specific type of message that has a fixed format, comprised of specified message fields. Each SIT number for an alert message provides information about the status of the beacon activation at the source MCC and/or information on the reason that the alert message was sent. ![Image 1 from page 71](/images/cospas-sarsat/G-series/G010/G010_page_71_img_1.png) ![Image 2 from page 71](/images/cospas-sarsat/G-series/G010/G010_page_71_img_2.png) 4-30 The formatting of a message according to the SIT number is generally independent of the data communications network that is used to transmit the message. However, every network imposes its own requirements on the packaging of the messages that it carries. Therefore, when a message that is received by an MCC is sent to another MCC, it may be necessary to re-format the message. An alert message received by an MCC will be formatted differently based on the alert destination type (e.g., an RCC or an MCC), and in many cases, based on the status of the beacon activation in the receiving MCC. 4.5.2 MCC to MCC Incident Alert Messages The formats of the incident alert messages that are used between MCCs are described in section B.5 of this Handbook. 4.5.3 MCC to RCC/SPOC Messages The incident alert messages that are sent from an MCC to its associated SPOCs and RCCs are in the SIT 185 format, which is designed to be read by a human operator. These messages are described in document C/S G.007, “Handbook on Distress Alert Messages for Rescue Coordination Centres (RCCs), Search and Rescue Points of Contact (SPOCs) and IMO Ship Security Competent Authorities”, and they are not explained in this Handbook. 4.5.4 System Information The system data messages that might be sent from or received by an MCC are in the SIT message formats described in section B.6 of this Handbook. 4.5.5 Narrative Messages The narrative messages that might be sent from or received by an MCC are in the SIT message formats described in section B.7 of this Handbook. 4.6 Quality Management System The Cospas-Sarsat Quality Management System (QMS) is implemented by the MCCs of the Ground Segment to assess the accuracy, availability, reliability and timeliness of alert data generated by LUTs, in accordance with document C/S A.003. Every MCC that has an associated LUT will receive the data that is collected from the reference beacons that have been designated for QMS analysis. This data is forwarded to its nodal MCC, which performs the analysis necessary to evaluate the quality of the data. Each nodal MCC then updates the appropriate status pages on the Cospas-Sarsat website, to ensure that the current status of each component is correctly displayed. 4-31 4.6.1 QMS Evaluation The performance indicators that are evaluated and reported by the Cospas-Sarsat QMS are identified in the following sections of this Handbook. When a problem is detected by the QMS processing and analysis, the nodal MCC will provide notification, to the responsible MCC in a SIT 915 message or to all MCCs in a SIT 605 message, depending on the significance of the problem, per document C/S A.003. In general, when a significant problem is detected, a SIT 605 message is sent and the C/S website is updated. If a significant problem with location accuracy is detected, this notification includes a request that the responsible MCC suppress all independent location data for operational beacons from the under-performing system, either Doppler solution data for a LEOLUT & satellite pair or DOA solution data for a MEOLUT. To ensure that inaccurate solution data is not distributed operationally, the same data that the responsible MCC is requested to suppress is also suppressed by: • the nodal MCC, and • all Central DDR MCCs (if the responsible MCC is in the Central DDR). For any System component that does not meet the required standard, the responsible operating agency is notified (through its associated MCC). That agency is then expected to investigate the deficiency and to report when the deficiency has been corrected. Following the suppression of independent location data, its operational use is resumed only after the nodal MCC determines that relevant accuracy requirements are being met for designated QMS reference beacons. LEOSAR For the LEOSAR system, the QMS provides information about the performance of each combination of LEOSAR satellite and LEOLUT for the following metrics: • Availability, • Location accuracy. For any combination that does not meet the appropriate evaluation criteria, the information is flagged on the LEOLUT QMS display on the Cospas-Sarsat website (available under the tab). GEOSAR For the GEOSAR system, the QMS provides information about the performance of each combination of GEOSAR satellite and GEOLUT for the following metric: • Availability ![Image 1 from page 73](/images/cospas-sarsat/G-series/G010/G010_page_73_img_1.png) ![Image 2 from page 73](/images/cospas-sarsat/G-series/G010/G010_page_73_img_2.png) 4-32 For any combination that does not meet the appropriate evaluation criteria, the information is flagged on the GEOSAR QMS display on the Cospas-Sarsat website (available under the tab). MEOSAR For the MEOSAR system, the QMS provides information about the performance of each MEOLUT for the following metrics: • Availability, • Local antenna availability, • Processing timelines, • Detection probability, • Location Probability, • Location accuracy, • Quality of location Expected Horizontal Error (EHE) estimate. For any MEOLUT that does not meet the appropriate evaluation criteria, the information is flagged on the MEOSAR QMS display on the Cospas-Sarsat website (available under the tab). MCC The QMS provides information about the performance of each operational MCC for: • Availability For any MCC that does not meet the required standards, the information is flagged on the MCC QMS display on the Cospas-Sarsat website (available under the tab). The under-performing MCC is expected to correct the problem as soon as possible. If a problem is allowed to continue for an extended period of time (as defined in C/S A.003), the under- performing MCC may be declared CNO (Commissioned, not operational), and eventually removed from the Cospas-Sarsat data distribution network. 4.6.2 MCC Roles in QMS Role of Nodal MCC The nodal MCCs are a key part of the Cospas-Sarsat Quality Management System (QMS). All data generated from designated reference beacons by Ground Segment components within a DDR must be forwarded to the associated nodal MCC, which analyzes the data to: • Compute the required quality performance indicators; ![Image 1 from page 74](/images/cospas-sarsat/G-series/G010/G010_page_74_img_1.png) ![Image 2 from page 74](/images/cospas-sarsat/G-series/G010/G010_page_74_img_2.png) ![Image 3 from page 74](/images/cospas-sarsat/G-series/G010/G010_page_74_img_3.png) 4-33 • Evaluate the performance of each LUT and MCC in its DDR; and • Report on any anomalies in the status of the Cospas-Sarsat Ground Segment, by: - Updating the status display on the Cospas-Sarsat website, and - Distributing status update messages to other MCCs, as appropriate. Based on the performance indicators, and on any other information that is available to it, the nodal MCC must determine if any Ground Segment component is degraded or not operational, and then make the appropriate declaration of the system status, so that other Ground Segment Providers can re-configure their systems, as appropriate. (For example, an MCC may have to filter out incident alert data from a component that is not capable of meeting its requirements.) The nodal MCC notifies the responsible MCC of any change of status of the System components that are associated with it. If the status of a component changes significantly, then the nodal MCC also notifies all Ground Segment Providers of the change in status. Each MCC operator may then make whatever configuration changes may be necessary to cope with the change of the System configuration and to work around any degradation that may have occurred. (For example, an MCC may be required to relay messages that would otherwise have gone through the degraded MCC to the appropriate destination RCC.) And when the component returns to full operation the MCC may have to restore the normal operational configuration. Role of All MCCs In support of the Cospas-Sarsat QMS, every MCC is required to send the reference beacon data, as specified in document C/S A.003 (System Monitoring and Reporting) to its nodal MCC. Beyond that, its only official responsibility is to respond to any reports of degradation or failure, and to restore its components of the Ground Segment to full operational status. However, there are other actions that can be taken by an MCC to ensure that the MCC and its associated Ground Segment components remain fully operational and compliant with the Cospas- Sarsat specifications. The document C/S A.003 lists a number of MCC self-monitoring parameters that an MCC should monitor on a regular basis to ensure that any potential degradation of performance is detected and corrected before it reaches the point where it is reported by the nodal MCC under the Quality Management System. There is no requirement that these self-monitoring parameters be reported or published; the only explicit requirement is that the Ground Segment components should be maintained in a fully operational state at all times. - END OF SECTION 4 - ![Image 1 from page 75](/images/cospas-sarsat/G-series/G010/G010_page_75_img_1.png) 5-1 5. MCC OPERATIONS 5.1 Management Each MCC is a critical part of the Cospas-Sarsat Ground Segment. As such, it must be available and ready to function at all times. The MCC specification (document C/S A.005, section 3.2.1) requires that “Once an MCC has been commissioned and attained Initial Operational Capability (IOC), it shall be in operation 24 hours per day, seven days a week, and personnel shall be available to satisfy the operational and performance requirements documented herein.” This means that an MCC must have personnel available full-time: twenty-four hours a day, seven days a week. In the event of any unexpected event, personnel must be available and ready to deal with it. It must be recognized that the organizations within the administrations that are responsible for the operation of the Cospas-Sarsat MCCs are varied, and include: • Government departments and agencies, • Military services, • Private contractors. Each of these organizations has its own internal policies and procedures which must be followed in the operation of the MCC to meet the requirements set by Cospas-Sarsat. As a result, it is not possible to identify or define a single approach to the management of an MCC that will work for all Ground Segment Providers. It is also noted that some MCCs are co-located with a national RCC, while other MCCs operate completely independently of the national Search and Rescue infrastructure. The selection and training of MCC personnel must accommodate and support: • The organizational structure of the national Administration, • The organization of the national SAR system, • The situation of the MCC within the national SAR infrastructure. The guidelines offered in this manual are based on the operations of many existing MCCs. They are neither comprehensive nor complete, and they are not intended to preclude other approaches to the operation of a national or nodal MCC. 5-2 5.1.1 Staffing Due to the complex and highly technical nature of MCC operations and the continuous evolution of the MCC requirements, dedicated resourcing and staffing are required to ensure that all the MCC functions are always performed correctly. For an MCC to have an operator on-site at all times, a full rotation of operational personnel will be required. To handle this workload (twenty-four hours per day and seven days per week, year- round) normally requires an MCC Manager and a minimum of four full-time operators. The exact number of operational personnel and the rotational schedule that is used by any MCC will be determined by the policies that control work hours at that MCC site. The personnel who may be available to operate an MCC will be limited by the nature of the organization responsible for that operation. However, when personnel are selected, some of the following areas of knowledge and experience will be useful to the person and to the MCC: • Search and Rescue operations (both nationally and internationally), • the region of responsibility of the MCC, • English-language communications skills, • communications networks and technology, • satellite operational issues, • maritime and aviation operational procedures, Of course, additional capabilities will be required for the managers and chief operators of an MCC. 5.1.2 Training When an MCC is commissioned (a Development MCC, or DMCC), one of the requirements is that the operating Administration must provide assurance that the personnel who will be working on the DMCC are fully trained and are capable of performing all of the functions that may be required of them during the operation of the system. Annex G to document C/S A.006 (MCC Commissioning Standard), the Declaration of DMCC on Operator Capability, includes a list of the specific capabilities that must be confirmed by the Administration that is requesting that its MCC be commissioned into the Cospas-Sarsat Ground Segment. This list represents a minimum requirement for the capabilities of an MCC operator. The Annexes to C/S P.015, “Cospas-Sarsat Quality Manual”, include an outline for a training program on the Cospas-Sarsat System, which would be useful for the prospective operators of an MCC. In additional to this general training on the Cospas-Sarsat System, an MCC operator must also be trained on the use of the specific equipment that is used by the MCC. This specific training will normally be available from the manufacturer(s) of that equipment. 5-3 Beyond this specific, hands-on, training of an operator, there is a need for a subsequent phase of on-the-job training. This training should be provided by an experienced MCC operator, and the trainee’s progress should be monitored and evaluated throughout the process. Once it has been accepted as a part of the Cospas-Sarsat Ground Segment, the MCC must provide whatever training and support may be required to maintain the capability of all of its operational personnel. This includes updating the knowledge of existing personnel as the Cospas-Sarsat System, and the MCC procedures and equipment, are enhanced over time, as well as training new personnel as they are hired by the MCC. To ensure that their staff remains current and maintains their skill, it is strongly recommended that each MCC should establish a standard for operator activity, considering their local situation such as the complexity of their ground segment and staffing models. For example, every MCC operator might be required to complete at least one full shift, consisting of at least eight hours duty, every thirty days. Additional individual tasks can also be required on a recurring basis to ensure proficiency of infrequent items. These can include a quarterly review of emergency activities (such as backup procedures or responses to equipment or communication failures), annual proficiency or refresher training events, and written exams. If any operator is not able to achieve the established performance standard, then an experienced operator should conduct a skills check, and further training as indicated, for that operator to ensure the continued safe operation of the MCC. 5.1.3 Voice Communications The MCC is required to maintain voice communications facilities to enable it to contact, as necessary, other MCCs and any of the alert destinations that are within its Service Area. This is normally a voice telephone capability, over the Public Switched Telephone Network (PSTN), but it may also include other communications facilities, such as radio communications facilities and Internet (voice over Internet protocol – VOIP) links. 5.1.4 Language The personnel at an MCC must be able to communicate with the RCCs and SPOCs that they support. This means that personnel must be available who can speak to each of these RCCs and SPOCs. Volume I of the International Aeronautical and Maritime Search and Rescue (IAMSAR) Manual, which is jointly published by ICAO and IMO, says that “The need for RCC staff and SAR unit crews to be proficient in speaking, writing and comprehending a common language to ensure effective information transfer is vital to successful conduct of SAR operations. In the case of a SAR action involving cooperative input from a number of RCCs and SRUs within a region, the most convenient language may be a common regional language. In the case of a SAR action likely to extend beyond regional areas, the appropriate common language is English. English, in any case, serves as the default SAR operational language in all cross-boundary operations where there is no other common language.” 5-4 Based on this guideline, every MCC should have on duty, at all times, at least one operator who is competent at communicating in the English language. A minimum level of competence on an internationally recognized measurement scale (such as the International English Language Testing System - IELTS - scoring) should be established to ensure that the operators are suitably qualified to support the MCC operations in communications with other organizations. In addition, and to the extent that is possible in each national context, it would be advisable to have available either: • An operator who can speak the language of each supported SPOC, or • An interpreter who can provide translation services for the operators, as necessary, when dealing with foreign SPOCs. While these are not mandatory, they will obviously facilitate the operations of the MCC in those situations where they may be called on. 5.2 Daily Operations The MCC is responsible for the administration and monitoring of the Cospas-Sarsat operations in its Service Area. This includes: • Managing all of the national contributions to the Cospas-Sarsat System, including (as appropriate): - The MCC itself, - Any part of the Cospas-Sarsat Space Segment that is provided by their national administration, - Any associated national LUTs, - Any reference beacons or beacon simulators that are operated by the national Administration, - The communications links between the MCC and each of the national components of the Cospas-Sarsat System, - The communications links between the MCC (if it is not a nodal MCC) and its nodal MCC, - The communications links between the MCC and any other MCC of the Cospas-Sarsat Ground Segment (as necessary), - The communications links between the MCC and each of its supported RCCs or SPOCs. • Monitoring the status of the Cospas-Sarsat operations that may affect the MCC Service Area, including the detection and reporting of any anomalies in any of: - The Cospas-Sarsat Space Segment, 5-5 - The operations of the LUTs within its Service Area, - The operation of its own MCC, - The operation of its associated nodal MCC, - The communications links to its associated nodal MCC, - The communications links to other MCCs within the same DDR (as relevant). • Maintaining an awareness of and an ability to access and search the International Beacon Registry Database (IBRD) that is operated by Cospas-Sarsat. • Maintaining an awareness of the contacts in all countries within the MCC Service Area: - The communications link addresses that are used to contact its associated RCCs and SPOCs, and any of the other alert destinations that it supports, - The current status of the communications links to each of those alert destinations, - The SAR capability of each of the RCCs and SPOCs that it supports, - The contact information for each national beacon register, - The current status of each national beacon register, - The current status of the communications facilities used to access each such register. • Maintaining an awareness of the back-up arrangements that may affect its operations: - The national back-up plans for this MCC, - The back-up plan for the nodal MCC, - the back-up plans for the other MCCs within the same DDR, - The back-up communications facilities for each potential alert destination, - The current state of each back-up configuration. • Collecting and forwarding to the nodal MCC all of the designated data required for the Cospas-Sarsat Quality Monitoring System (QMS) As any limitations or failures are reported in the Cospas-Sarsat Ground Segment within its Service Area, the MCC must distribute the appropriate information to all interested parties, and must take any action within its capabilities to configure the system to operate in backup mode, and to restore the system to full operational capabilities as soon as that becomes possible. 5.2.1 Activities for MCC System Manager The MCC System Manager is the manager of the MCC operations and must be aware of the status of the MCC, including both the equipment and the personnel, at all times. He or she must also maintain an awareness of the Cospas-Sarsat System, especially as it may affect the operations of the MCC. 5-6 Although the MCC System Manager should be available (that is, on call) at all times, it is not essential for a manager to be on-site all the time. It is necessary only that they should be available to the duty operator whenever their services may be required. Some of the duties of the MCC System Manager will be: • Managing the operations of the MCC, including an awareness and control of the operational status and conditions: - The MCC, - The MCC personnel, - The MCC equipment, - The MCC communications systems, - All related national contributions to the Cospas-Sarsat System. • Managing the support for the testing of various parts of the Cospas-Sarsat System, including: - Spacecraft commissioning, - MCC commissioning, - LUT commissioning, - Beacon type approval, - Testing of reference beacons and beacon simulators. • Liaison with the managers and personnel of: - The neighbouring MCCs, - All supported RCCs, - All supported SPOCs. • Liaison with the operational staff responsible for the national contributions to the Cospas- Sarsat System, including (as appropriate): - The Space Segment, - Any associated LUT, - Any reference beacon or beacon simulator, - The operational staff at each associated LUT (as appropriate). • Liaison with others who may be involved (directly or indirectly) in the national participation in the Cospas-Sarsat Programme: - The national Representative to Cospas-Sarsat, - The management of the national Agency participating in the Cospas-Sarsat Programme, 5-7 - The management of the national agencies who are responsible for Search and Rescue, - The management of the national agencies who are responsible for Air Traffic Control, - The management of the national agencies who are responsible for the control of maritime traffic. • Maintaining an awareness of the current status of all other components of the Cospas-Sarsat System, including: - The Space Segment, - The Ground Segment (especially within the local DDR), - The distress beacon population, - The Search and Rescue authorities and operations with in the MCC Service Area, • Participation in (or organizing the national delegation for) any meetings that relate to the operation of the MCC, which may include: - National meetings, - Meetings of representatives of the local Data Distribution Region, as organized by the nodal MCC, - Cospas-Sarsat Meetings, including (as appropriate for this national delegation) meetings of the: ▪ Cospas-Sarsat Council, ▪ Cospas-Sarsat Joint Committee, ▪ Experts Working Groups (as invited), ▪ Task Groups, ▪ Correspondence Working Groups, - Any other meetings (as appropriate). These duties and responsibilities will be supplemented, as necessary, by others from time to time. 5.2.2 Activities for MCC Operator An MCC operator should be capable of performing any of the activities that may be required to support the national MCC, including: • Operating and monitoring the operations of: - The MCC equipment, - The MCC communications links, - Any other equipment that is installed at the MCC and used by the MCC during its operations. 5-8 • Communications with related organizations, including: - Other MCCs, - Supported RCCs, SPOCs, and other distress data authorities, - The organization that manages associated LUTs, - The organizations that manage other Cospas-Sarsat ground equipment (such as reference beacons and beacon simulators). The MCC operator should also maintain an awareness of the status of the Cospas-Sarsat System, especially of those components of the System that are within the local DDR and also including the Cospas-Sarsat Space Segment. An MCC operator may also be called upon to support any of the activities listed above (in section 5.2.1) for the MCC System Manager. In particular, this may include participation in any of the meetings that are listed. 5.2.3 Monitoring the Operation of MCC The operation of an MCC must be monitored at all times, both by the MCC personnel and by the associated nodal MCC. This requires that the operator monitor several aspects of the operation of the MCC: • The functions and performance of the MCC must be monitored on a regular basis, including the self-monitoring recommended in section 3.1.4 (MCC Self-Monitoring) of document C/S A.003. The details of the monitoring that is expected of an MCC are discussed in more detail in section 5.3.2 of this Handbook. • The performance of the other components of the national Cospas-Sarsat ground segment must be monitored, including the self-monitoring recommended in section 3.1 (Ground Segment Self-Monitoring) of document C/S A.003 and as discussed in more detail in section 5.3.2 of this Handbook. • The operation of the MCC must be watched, to ensure that the operator is aware of any activity that may require human intervention. The following messages must be reviewed as they are received: - Narrative messages, - System status messages, - Any other messages with information about the state of any part of the System. In each case, the appropriate action should be taken. If appropriate, a response should be prepared and sent. Beyond these specific monitoring capabilities, the personnel at an MCC should maintain an awareness of the status of operation of all components of the Cospas-Sarsat System and of all 5-9 related and dependent systems that it supports. If any anomalies in the operation of the System are observed, they should be reported to the appropriate authority. 5.2.4 Test Procedures An MCC is responsible for coordinating any tests involving C/S beacons that may be performed within its area of responsibility. This includes the activation of test or reference beacons in support of: • Commissioning of LUTs and MCCs, • Type approval of beacons, • Beacon tests, • Search and Rescue tests and exercises, • Communications tests, • Cospas-Sarsat System tests. Related MCC responsibilities are described in sections “Exchange of Test and Exercise Data” and “Procedures for the Co-Ordination of Beacon Tests” of document C/S A.001. Commissioning Tests The Administration that is responsible for the MCC may install or upgrade various components of the national ground segment. Those Participants who are Space Segment Providers will, at intervals, launch new spacecraft to serve the System. As each component is put into place, the associated MCC will be responsible for the coordination of the tests that are associated with the commissioning of the new components. These commissioning tests often require the activation of one or more test beacons or beacon simulators to provide the data needed for the test. The details of the requirement for the commissioning of the Space Segment and the Ground Segment of the Cospas-Sarsat System are described in more detail in Annex F.1 of this MCC Handbook. Beacon Type Approval Before a 406 MHz beacon can be marketed for use with the Cospas-Sarsat System, it must undergo a series of rigorous tests to confirm that the design and implementation of that beacon meets the relevant requirements specified in document C/S T.001 (for First Generation Beacons) or document C/S T.018 (for Second Generation Beacons). The type approval of a beacon is the responsibility of the manufacturer of the beacon, and is based on a set of tests and measurements that are defined in the various type-approval documents that are listed in Table 5-1. ![Image 1 from page 84](/images/cospas-sarsat/G-series/G010/G010_page_84_img_1.png) ![Image 2 from page 84](/images/cospas-sarsat/G-series/G010/G010_page_84_img_2.png) 5-10 Table 5-1 – Beacon Type Approval Documents Document Number Title T.007 Cospas-Sarsat 406 MHz Distress Beacon Type Approval Standard T.008 Cospas-Sarsat Acceptance of 406 MHz Beacon Type Approval Test Facilities T.015 Cospas-Sarsat Specification and Type Approval Standard for 406 MHz Ship Security Alert (SSAS) Beacons T.021 Cospas-Sarsat Second-Generation 406-MHz Distress Beacon Type Approval Standard C/S T.IP (LIRB) Interim Procedure for Type Approval of 406 MHz Beacons Equipped with Li-Ion Rechargeable Batteries C/S T.IP (TCXO) Interim Procedure for the Determination of Compliance of 406 MHz Beacons Equipped with a TCXO with Cospas-Sarsat Type Approval Requirements The type-approval standards define the procedures for the type approval of each type of beacon. The process begins with an application from the beacon manufacturer, which includes a set of documents (as listed in each type-approval standard). These documents are reviewed by the Secretariat and by an Experts’ Working Group (EWG) that is convened by the parties. Once the application has been reviewed and found to be in order, the type-approval tests and measurements are performed by a certified test laboratory. The laboratories must have been certified by the Cospas-Cospas Parties, according to the requirements defined in document C/S T.008. The other documents that are listed in Table 5-1 describe all of the tests and measurements that must be performed and reported, for each different type of beacon, before the beacon can be type-approved. Once the tests and measurements have been performed, the report of these results is referred back to the EWG for review. The experts determine whether or not these results confirm that the beacon meets the relevant requirements. If there are any questions about the results, or about the performance of the beacon, the report may be sent back to the manufacturer, and clarification or further tests may be requested. When the EWG is satisfied that the beacon meets the requirements established by the Cospas- Sarsat specifications, they recommend that the Parties approve the beacon for use with the System. The Parties, working through the Cospas-Sarsat Secretariat, assign a Type-Approval Certificate (TAC) to the beacon, and the beacon may then be marketed as a Cospas-Sarsat 406 MHz distress beacon. The beacon type-approval process does not directly involve or require the participation of any Cospas-Sarsat MCCs. However, some of the type-approval tests may require the activation of a 5-11 test beacon; for all such tests, the MCCs that may be involved must be notified and approve of the test. The completion of a successful Beacon Type Approval test does not necessarily qualify a beacon for operational use. Each Administration defines the rules and regulations that control the use of a distress beacon within its own jurisdiction. Document C/S S.007 (Handbook of Beacon Regulations) has been compiled from the contributions of the Participants in the Cospas-Sarsat Programme to provide regulations for the permitted use of distress beacons in the different jurisdictions. Beacon Tests Live tests of individual beacons may be required for various reasons. One example is the need to check on the operation of a beacon after it has been involved in an incident, especially if there is some question about how it performed during that distress incident. In each such case, the MCC must evaluate the validity of the reason for the test and the potential impact on any current SAR activity and make a decision on whether or not to allow the test to proceed. Search and Rescue Exercises Exercises that require the activation of a distress beacon may arise through the normal course of Search and Rescue activity. They may be a part of a national training program or an international cooperative effort. Or they may be a part of an evaluation of the effectiveness of the Cospas-Sarsat System or other components of the international SAR programs. In general, any such exercise will be reviewed and planned by higher-level agencies before they are proposed to the Cospas-Sarsat MCCs. However, each MCC must evaluate the impact on SAR activities in its own Search and Rescue Region before it agrees to participate in the exercise, or to allow the activation of distress (or test) beacons in its Service Area. 5.2.5 MCC Operational Backup As noted in section 4.1.2 of this Handbook, the MCC must include provision for backup capabilities. The backup provisions may include the operation of a separate backup MCC system (complete with separate communications links, as necessary). Alternately the backup may be implemented by an agreement with a neighbouring MCC to take over some or all of its operations when the national MCC temporarily fails. In some cases, especially for nodal MCCs, both types of backup arrangements are set in place. The backup arrangements for each MCC are documented in the individual entries in section 5.3 (Description of Cospas-Sarsat MCCs) of C/S A.001. Each MCC should ensure that the relevant section of C/S A.001 specifies whether the backup MCC will support the SPOCs of the failed MCC directly, or whether it will go through a national point of contact for each SPOC. ![Image 1 from page 86](/images/cospas-sarsat/G-series/G010/G010_page_86_img_1.png) ![Image 2 from page 86](/images/cospas-sarsat/G-series/G010/G010_page_86_img_2.png) 5-12 These backup provisions are addressed further in section D.1 of this Handbook. 5.3 Monitoring and Test Activities As noted in section 4.1.2 of this Handbook, an MCC is expected to monitor its own performance and the performance of any other portions of the Cospas-Sarsat System that are operated by the Administration that is responsible for the MCC. When an MCC is commissioned, according to the requirements of document C/S A.006 (MCC Commissioning Standard), it must go through an Initial Operational Capability (IOC) phase, a period of monitored operations to confirm that it is ready for full operational use. During this IOC, all other MCCs are expected to monitor the operations of the new MCC to verify that it fully meets the requirements of the specifications and the operational documents. The Cospas-Sarsat Quality Management System (QMS) is defined in documents C/S P.015, “Cospas-Sarsat Quality Manual”, and C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”. These documents identify some specific requirements for the monitoring of the operations of an MCC and of the associated national ground segment contributions. In addition, document C/S A.003 provides descriptions and specifications for a number of MCC self-monitoring parameters. While the monitoring of these parameters is not officially required of an MCC, they are recommended to ensure that the MCC management remains aware of the status of the MCC and the associated LUTs and is aware of any potential degradation before it begins to affect the operational use of the MCC or the associated LUTs. Finally, document C/S A.005 (MCC Performance Specification and Design Guidelines) requires that the MCC “shall monitor the following System elements in its national Ground Segment”: • Its own (MCC) operations, • Associated LUTs and LUT/MCC communications links, • External communications with all data recipients, • Any anomalies in the operation of the Cospas-Sarsat System. As any anomaly is detected by the MCC, it should be reported to the associated nodal MCC and to any other MCC that might be affected by the issue. 5.3.1 MCC Commissioning As each MCC is developed and introduced into the Cospas-Sarsat System, it must go through a commissioning process; a set of tests that verify that it meets the required specifications and is ready to participate in the Cospas-Sarsat Ground Segment at Full Operational Capability (FOC). The requirements for a Cospas-Sarsat MCC are specified in document C/S A.005 (MCC Performance Specification and Design Guidelines). The procedures for the commissioning of an 5-13 MCC are described in document C/S A.006 (MCC Commissioning Standard). In addition to the requirements for the commissioning of every new MCC, the document C/S A.006 also describes the requirements for commissioning a nodal MCC and for re-commissioning an MCC that has been modified or enhanced after its original commissioning. The overall procedure for commissioning is explained in Annex A (“Guidelines for Integration of New MCCs in the Cospas-Sarsat System”) of C/S A.006, which is provided as “a textual flow- chart which sketches procedures for integrating an MCC under development (DMCC) into the existing Cospas-Sarsat Ground Segment”. It is intended to provide guidance to the Joint Committee “to manage and coordinate the introduction of new MCCs into the existing Ground Segment” and “to assist the DMCC in planning and performing the appropriate integration tests”. That Annex A is divided into a series of steps to be followed as the new MCC is developed and integrated into the System. Initial Ground Segment Description and LUT Coverage Step A is to provide information “to assist the Joint Committee in deciding how the DMCC best fits into the existing System”. This includes information about the LUTs that will be associated with the DMCC, and about the proposed Service Area of the DMCC. The DMCC is required to provide the Cospas-Sarsat Secretariat with all the information that will be required to update the Cospas-Sarsat web site and the Cospas-Sarsat documents (such as C/S A.001) to include the new MCC. During this step, the DMCC may propose the host MCC (HMCC), which will coordinate and oversee the commissioning of the new MCC into the System. Assignment of Service Area and Message Distribution Procedures Step B is then intended to “determine the DMCC's responsibilities within the Cospas-Sarsat MCC network”. The Joint Committee will select (or confirm, as appropriate) the HMCC for the commissioning of this DMCC. The Joint Committee will review the proposed MCC Service Area, following the policy that is defined in document C/S P.011, “Cospas-Sarsat Programme Management Policy”. During this stage, the DMCC must identify (and notify the HMCC of) the responsible authorities to which it will distribute incident alert messages. Before the start of the formal MCC commissioning tests, the DMCC will perform tests to confirm that it has the necessary infrastructure in place to format and to transmit the incident alert message to each of the SPOCs in its proposed Service Area. ![Image 1 from page 88](/images/cospas-sarsat/G-series/G010/G010_page_88_img_1.png) ![Image 2 from page 88](/images/cospas-sarsat/G-series/G010/G010_page_88_img_2.png) 5-14 Integration Test The formal integration test in Step C is intended to “test the DMCC's operational readiness and compliance with Ground Segment requirements.” Based on past experience, it is recommended that the HMCC and DMCC hold a planning meeting “over two or three days, if necessary”. During this meeting, they can review the results of the preliminary tests, and can prepare a DMCC Commissioning Test Plan that describes the detailed plans for the commissioning tests. At this stage, the DMCC must confirm that it understands and will comply with all the operational requirements for an MCC in the Cospas-Sarsat Ground Segment. The commissioning tests will be scheduled, and all MCCs involved will be notified of the planned tests. The intent of the commissioning tests is to evaluate all aspects of the operation of the DMCC. This specifically includes the performance of the DMCC operators. For this reason, the DMCC commissioning tests should be performed by the people who will operate the MCC when it is fully operational. Other personnel, including management, maintenance staff, and vendor support persons, may respond to requests (in the same way as they might during normal operations). However, they should not conduct the tests or operate the MCC during the commissioning test period. These other personnel may also assist in the collection of data and the preparation of the draft MCC Commissioning Report. The only restriction is in the actual operation of the DMCC during these commissioning tests. As the tests are run, each MCC will monitor the results, and will notify the DMCC of any anomalies that they observe. The DMCC will correct any deficiencies and schedule a repeat of the appropriate test(s). As the tests are completed, the DMCC will prepare a DMCC Commissioning Report; when that report is ready, it will be submitted to the HMCC for review and completion. Establishment of Initial and Full Operational Capability Step D will start the operation of the DMCC at Initial Operational Capability (IOC), and then (if all goes well) the DMCC will proceed to Full Operational Capability (FOC) at a scheduled date. As specified in document C/S A.006 section “Establishment of Initial and Full Operational Capability”, the FOC date is automatically set at the IOC date plus 90 days, or as agreed with the Joint Committee prior to integration testing. The IOC phase can be extended by up to an additional nine months, if problems are discovered during the operation of the MCC. Note that one of the major differences of the operations of an MCC during the IOC phase is that it will support only its own national RCCs in its declared Service Area. For a new MCC, the other SPOCs in the declared Service Area will continue to be served by the MCC that was supporting them before the new MCC was planned. As noted in document C/S A.006 section ![Image 1 from page 89](/images/cospas-sarsat/G-series/G010/G010_page_89_img_1.png) ![Image 2 from page 89](/images/cospas-sarsat/G-series/G010/G010_page_89_img_2.png) 5-15 “Recommissioning of a Previously Commissioned MCC”, if the upgraded MCC maintains an “operational” status, it shall continue to distribute alert data to its associated SPOCs, unless the associated nodal MCC determines that continued distribution poses a significant risk that the associated SPOCs will not receive timely, reliable alerts. Since an extended period of such support (in addition to its normal responsibilities as an MCC with its own Service Area) can impose a significant hardship on the MCC that backs up the DMCC, the planned duration of the IOC phase may be reduced in such a situation. (This is especially true if the re-commissioning was due to an enhancement of the DMCC, and not to a failure of the existing DMCC system.) The HMCC must confirm that the DMCC Ground Segment Provider has completed the formalities necessary to become a participant in the Programme, and that the commissioning tests have been successfully completed. The HMCC can then declare the DMCC at IOC and notify the other MCCs that this new MCC is operational (at IOC). (If there are minor deficiencies, the HMCC may allow the DMCC to go to IOC, as long as there is a plan to correct the problems before FOC is declared.) During this IOC phase, the DMCC participates in all Ground Segment operations, but it is restricted to supporting only its own national area in the declared MCC Service Area. The HMCC directs the activity of the DMCC during this IOC phase and any problems that are detected with the DMCC during this period should be reported to the HMCC. Before declaring the DMCC at IOC, the HMCC sets a date for the advance of the DMCC to FOC. Before that date, the HMCC will arrange, through its Representative to Cospas-Sarsat, to submit the DMCC Commissioning Report to the Secretariat, for review and recommendation by the Joint Committee and for approval by the Council, at the next suitable opportunity. When the date arrives, and assuming that there have been no problems during the IOC phase, the DMCC will move to FOC. The HMCC will notify all other MCCs of the change of status. All MCCs (including the DMCC and HMCC) will re-configure as necessary so that the DMCC supports all the SPOCs in its declared Service Area If there are problems observed during the IOC phase, they must be corrected before the DMCC can proceed to FOC. If the problems are not serious, they may be corrected during the IOC phase. (This IOC phase may be extended, if necessary. However, the total duration of the IOC phase may not be extended to be more than one year from the initial declaration of IOC.) If the MCC is not able to transition to FOC at the end of the one-year period, the new MCC will be considered not operational and will be documented as “under development”; the system should be repaired so that it can pass the commissioning, and a new commissioning should be scheduled. Note that, although the DMCC Commissioning Report may not be reviewed and approved immediately, the DMCC will proceed to FOC as scheduled, as long as the HMCC is satisfied that it has performed correctly during the IOC phase. Limited Re-Commissioning of an MCC Limited MCC re-commissioning is described in document C/S A.006 section “Recommissioning of a Previously Commissioned MCC”. ![Image 1 from page 90](/images/cospas-sarsat/G-series/G010/G010_page_90_img_1.png) 5-16 5.3.2 Monitoring the National Ground Segment The national ground segment of a Cospas-Sarsat Ground Segment Provider may include one or more of: • The national MCC and a backup MCC, • Associated LUTs, • Reference beacons and beacon simulators, • Communications links. In addition to these specific System components, the MCC is expected to be aware of the operation of the entire Cospas-Sarsat System, and to report or otherwise respond to any anomalies in the operation of any part of that System. MCC Monitoring An MCC is required to monitor all communications that it transmits or receives, to ensure that the data is correctly received at the intended destination. The MCC is also required to maintain records of all information that it receives and processes. Any anomalies in the processing or communications of the data by the MCC are to be reported to the MCC operator. In addition, document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”, identifies several performance parameters to be monitored during the operation of an MCC. Some of these are a part of the Cospas-Sarsat Quality Management System (QMS), whose regular monitoring is required by the MCC specification (document C/S A.005), and others are MCC self-monitoring parameters, whose monitoring is recommended but not required. The personnel at an MCC should be aware of the state of each of these performance indicators and should take action if any of them indicate a degradation in the performance of the MCC. If the MCC is not performing all of its functions to the level required by the specification and the other operational documents, the MCC manager should be notified, and take action accordingly: • If possible, the anomaly should be corrected and the MCC returned to its full operational capability as soon as possible. • If the anomaly prevents the proper operation of the MCC, the appropriate backup arrangements should be activated. • If the anomaly cannot be corrected quickly, the associated nodal MCC (and any other MCCs that may be affected by the anomaly) should be notified. If the anomaly continues for any significant length of time, the MCC may be set to a “Commissioned, not Operational (CNO)” status. The details for the process of determining when an MCC is CNO, and for returning to normal operational status, are described in section 6.3.4 of document C/S A.003 and in section 2.5 of document C/S A.006 (MCC Commissioning Standard). ![Image 1 from page 91](/images/cospas-sarsat/G-series/G010/G010_page_91_img_1.png) 5-17 The monitoring of the performance of an MCC is not restricted to the performance of the MCC equipment (such as the computer system that performs much of the operational functions of the MCC); it should also include the performance of the MCC personnel and the MCC communications links. LUT Monitoring For a Ground Segment Operator that operates one or more Local User Terminals (LUTs), the MCC is also expected to monitor the operation of those LUTs, including the communications links between each LUT and the MCC. If any anomaly is detected in the performance of an associated LUT, then it should be reported and addressed, in a manner similar to that recommended for an MCC anomaly in section 5.3.2.1 above. Monitoring other Ground Segment Components A Ground Segment Operator that operates other equipment in the Cospas-Sarsat Ground Segment, such as a reference beacon or beacon simulator, is also expected to monitor the operation of that equipment, including any associated communications links. If any anomaly is detected in the performance of any associated Cospas-Sarsat Ground Segment equipment, then it should be reported and addressed, in a manner similar to that recommended for an MCC anomaly in section 5.3.2.1 above. 5.3.3 Communications Link Monitoring Data communications facilities form a key part of the Cospas-Sarsat data distribution system. These facilities may be private communications links, or they may be part of larger commercial communications networks. They are generally designed for fully automatic operation, under the control of the computer systems in the MCCs. Communications Networks As explained in section 4.4, document C/S A.002, “Cospas-Sarsat Standard Interface Description” (the SID), includes a set of Annexes that describe the protocols that should be used with the communications networks that are considered suitable for use. For each of the different communications links that are supported by an MCC, the MCC specification (document C/S A.005) defines the reliability level that it is expected to maintain while it is in service. These reliability levels are stated in each of the following sections. The document also specifies the volume of data that the MCC and the associated communications links shall be capable of processing. ![Image 1 from page 92](/images/cospas-sarsat/G-series/G010/G010_page_92_img_1.png) ![Image 2 from page 92](/images/cospas-sarsat/G-series/G010/G010_page_92_img_2.png) ![Image 3 from page 92](/images/cospas-sarsat/G-series/G010/G010_page_92_img_3.png) 5-18 Communications Links with Associated LUTs As noted above, the communications between an MCC and its associated national LUTs is determined by the national Administration, as a matter of national prerogative. In fact, the primary determinant is usually the distance between the systems. If the LUT and MCC are located close together, then the link is usually a direct cable link, using the Internet protocols between the two systems. If the distance is too far for a simple cable link, then the choice of the communications facility is determined by the availability of the service. If the Administration has a private communications network available, then that network will probably be used. Otherwise, a commercial network (using the Internet protocols) is the most likely choice for this link. Although the SIT message formats that are described in the SID are not explicitly designed for LUT to MCC communications, and are not mandatory, most LUT to MCC communications links make use of these formats. The message formats may be extended to include variations on the SIT formats, possibly with extra message data fields, to support the additional data that may be available from the LUT (and of interest to the associated MCC). The link between an MCC and each of its associated LUTs is required to be operational at least 99% of the time. Communications Links with National RCCs The communications between an MCC and its associated national RCCs is determined by the national Administration, as a matter of national prerogative. Again, the primary determinant is usually the distance between the systems. If the MCC and RCC are located close together, then the link is usually a direct cable link, using the Internet protocols between the two systems. If the distance is too far for a simple cable link, then the choice of the communications facility is determined by the availability of the service. If the Administration has a private communications network available, then that network will probably be used. For aviation RCCs, the AFTN, which is available and supported by the national aeronautical infrastructure, may be used. Otherwise, a commercial network (using the Internet protocols) is the most likely choice for this link. The SIT message formats that are defined in the SID are not mandatory for use with a national RCC. However, the SIT 185 message format, which is officially defined specifically for use with a foreign SAR Point of Contact (SPOC), contains most of the data that is of interest and of use to the Search and Rescue personnel at an RCC. And the SIT 185 message format is not as fixed as the other SIT message formats, so the contents of the message can be varied without violating the message format described in the SID. In addition, the MCC has the software to generate these messages for foreign SPOCs, so it is normally just a matter of configuration to use the same software with a national RCC. As a result, most MCCs use some variants of the SIT 185 message format to send incident alert data to their own RCCs. ![Image 1 from page 93](/images/cospas-sarsat/G-series/G010/G010_page_93_img_1.png) ![Image 2 from page 93](/images/cospas-sarsat/G-series/G010/G010_page_93_img_2.png) 5-19 The link between an MCC and each of its associated national RCCs is required to be operational at least 95% of the time. Communications Links with Foreign MCCs The SID specifies the communications links between operational MCCs. It is mandatory (as specified in document C/S A.005) that all MCCs use the networks and protocols that are identified in the SID. Because the cost of the service is normally well-defined, as a monthly price for a connection to the Internet, and because the available Internet services are generally capable of the high data rates that may provide the best service, most links between MCCs are carried over the Internet; in particular, these links use the FTP/VPN protocol. The links between MCCs require a backup service, to ensure that the communications will continue to be available even if the primary link fails. This backup service may be a separate Internet link (which must use completely separate cable links, to ensure that there is no potential single point of failure), or it may be a separate AFTN link. In a few cases, where no other alternate communications service is available, secondary communications service is provided by email (which should use an independent communications link). The link between an MCC and any other MCC is required to be operational at least 99% of the time. Communications Links with Foreign SPOCs Although the System allows for bilateral agreements for different communications links and protocols, most of the existing operational MCC-SPOC links follow the directions laid out in the SID. The actual network that is used normally depends on the availability of the service at each SPOC. If the SPOC has Internet service available, and because the Internet link is already available at the MCC, most MCCs prefer to communicate with their SPOCs over the Internet, using the FTP/VPN protocol. However, if the Internet is not available at the SPOC, an AFTN link may be used. The link between an MCC and each of its foreign SPOCs is required to be operational at least 95% of the time. Communications Links with SSAS Competent Authorities The communications links between an operational MCC and the SSAS Competent Authorities is determined by mutual agreement between the MCC and each Competent Authority. The actual network that is used normally depends on the availability of the service at each facility. If an Internet service is available, and because the Internet link is already available at the MCC, MCCs may prefer to communicate with their SSAS Competent Authorities over the Internet, using ![Image 1 from page 94](/images/cospas-sarsat/G-series/G010/G010_page_94_img_1.png) ![Image 2 from page 94](/images/cospas-sarsat/G-series/G010/G010_page_94_img_2.png) ![Image 3 from page 94](/images/cospas-sarsat/G-series/G010/G010_page_94_img_3.png) 5-20 the FTP/VPN protocol. However, if the Internet is not available at the Competent Authority, another link may be used. The link between an MCC and each of its SSAS Competent Authorities is required to be operational at least 95% of the time. Communications Links with Return Link Service Providers The links with a Return Link Service Provider (RLSP) are only relevant to MCCs that communicate directly with an RLSP. See document C/S A.005 section “Data Communication Links” for further information. The link between an MCC and its associated RLSP is required to be operational at least 95% of the time. Communications Links with the Location of an Aircraft in Distress Repository The communications links between an operational MCC and the Location of Aircraft in Distress Repository (LADR) that is operated under the direction of the ICAO are only relevant to nodal MCCs. See A.005 section “Data Communication Links” for further information. The link between an MCC and the LADR is required to be operational at least 95% of the time. Data Communications Monitoring Each MCC is expected to monitor each of its communications links to ensure that the incident alert (and other) messages are successfully received by the appropriate destination facility. For any communications service that provides confirmation of successful transmission, the sending facility should verify that the confirmation is correctly received after each message has been sent. As messages are received from other MCCs, the sequence numbers of the messages should be verified, to ensure that no message has been lost in transmission. And every message that is received must be validated, to ensure that the data is correctly encoded, according to the specifications for the SIT message format and each of the Message Fields that are contained in the message, according to the requirements of the SID. If any message is not received correctly by the MCC, then the sending MCC should be notified of the error and asked to re-transmit the message. The two MCCs should coordinate their verification of the messages to ensure that the communications link is working correctly. ![Image 1 from page 95](/images/cospas-sarsat/G-series/G010/G010_page_95_img_1.png) ![Image 2 from page 95](/images/cospas-sarsat/G-series/G010/G010_page_95_img_2.png) ![Image 3 from page 95](/images/cospas-sarsat/G-series/G010/G010_page_95_img_3.png) 5-21 Communications Link Tests The various communications links that connect the MCC to its associated LUTs, to other MCCs, and to the different alert data recipients that it supports are all described in section 4.4.1 of this Handbook. Each of these communications links must be maintained in a reliable state, so that they will work correctly whenever they are required. If the link is in relatively continuous use, then no further testing may be required. However, for a link that is not frequently used, occasional testing is required to ensure that it will always be available. The testing that is required for each SPOC communications link is identified in C/S A.005 and described in section F.3 of this Handbook. As long as there is operational message traffic over a communications link, the validation and verification of the messages that are sent and received over that link is sufficient to confirm that the communications are working correctly. For any communications link that is not used on a regular basis, it is necessary to test the link. This is particularly true of the links between an MCC and the SPOCs that it supports. In the nature of Search and Rescue operations, it is possible that there may be no distress incidents, and therefore no incident alert messages, over the course of a year. In any such case, the responsible MCC is expected to generate one or more test messages to send to the SPOC, and to request confirmation from the SPOC that the message has been correctly received. The reports of these communications tests are included in the Status and Operations Report that the MCC sends to the Cospas-Sarsat Secretariat each year for review by the Cospas-Sarsat Joint Committee. From these reports, the Secretariat compiles a summary of the status of the SPOCs (and their communications links) for presentation to the Joint Committee. After review, this summary may be forwarded to ICAO and IMO for their information. These organizations, pursuing their interest in and commitment to search and rescue, may take action to improve the quality of services that can be provided by the RCCs involved. If the receipt of the test messages to any SPOC is not confirmed as expected, the responsible MCC should make other attempts to contact the SPOC, and to ensure that the SPOC and the associated communications services are operating correctly. If the SPOC cannot be contacted and its correct operation confirmed, then the MCC should make whatever effort is necessary to ensure that incident alert data for the country in question will be responded to appropriately. This may require the identification of a new SPOC. Where there is unusual difficulty in identifying a SPOC for a particular region or nation, the MCC may request assistance from ICAO, IMO, or other appropriate international organizations. If no other effort leads to the successful identification of a SPOC that can receive and respond to incident alerts, the MCC may have to deliver the alert to another RCC (probably in the State that operates the MCC), and ask that RCC to follow through, according to its own operating procedures, to ensure that the alert is dealt with appropriately. ![Image 1 from page 96](/images/cospas-sarsat/G-series/G010/G010_page_96_img_1.png) 5-22 5.3.4 Space Segment Monitoring After each satellite of the Cospas-Sarsat Space segment is launched, it goes through a commissioning evaluation, as described in the appropriate commissioning document (document C/S T.004, C/S T.013, or C/S T.017, as listed in Table 2-6). Unlike the LUT and MCC commissioning standards, these commissioning standards are not pass-or-fail tests. Because the spacecraft of the Cospas-Sarsat Space Segment are satellites of opportunity, designed for a different primary mission and donated by the Space Segment Provider for the use of the System, the Cospas-Sarsat Programme does not produce any specification for the SAR payloads, and there are no direct criteria for acceptance or rejection of the payloads. In addition. once the satellite is in orbit, it cannot be returned for repair. And it cannot easily be replaced. So, the intent of the commissioning of the spacecraft is to characterize its performance. This provides a description and a baseline which can be used by the Cospas-Sarsat Ground Segment to manage the processing of the data received through each spacecraft. There are no explicit requirements for the monitoring of the Cospas-Sarsat Space Segment in the MCC specifications (in C/S A.005) or in the other operational documents (A.001, A.002, or A.003). However, each MCC receives and processes data that has passed through and been processed by one or more of the components of the Space Segment; as a result, it has the opportunity to review this data and to note when any anomalies occur. In addition, the MCC personnel are in contact with the RCCs who use data from the Cospas-Sarsat System, and who will notice any unusual or suspect data. During the operation of the system, the Space Segment is monitored in various ways: • The Space Segment Providers regularly monitor and test their spacecraft, using their own LUTs and other specialized test facilities. • The Quality Management System (QMS) requires every MCC to report certain data to its associated nodal MCC, which analyses the data and reports on any anomalies that are discovered during this analysis. • The MCC self-monitoring, described in document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”, may result in the detection and reporting of an anomaly in the operation of one of the spacecraft of the Cospas-Sarsat Space Segment. Whenever the staff at an MCC become aware of any anomaly in the operation of any part of the Cospas-Sarsat System, they should investigate or report it to the Participating State that is responsible for the component that may be causing the problem. If it is not clear which component(s) may be at fault, then the problem may be reported to the associated nodal MCC for further investigation. In cooperation with the nodal MCC, the MCC should ensure that the anomaly is clearly pointed out to the responsible Participant and is dealt with appropriately. When a nodal MCC is informed of a potential satellite outage, it will update the QMS status display on the Cospas-Sarsat website to show the current status of the spacecraft involved. The nodal MCC will also notify the Space Segment Provider who is responsible for that spacecraft. The Space 5-23 Segment Provider will then (in cooperation with the Ground Segment Provider who initially reported the issue and the nodal MCC) perform whatever further analysis may be necessary to identify the cause of the problem, and will determine what action is required to address the problem. The Space Segment Provider will notify the Ground Segment Providers, through a SIT 605 System status message from its associated MCC, of the situation, and of the current status of the spacecraft. The action that may be taken to address a spacecraft problem may be any of a wide range of options. The Space Segment Provider may: • Issue commands to the spacecraft, to change the configuration to bypass any component that is not operating correctly. • Issue commands to the spacecraft, to change the orbit to avoid a situation that may cause the problem. • Recommend changes to the Ground Segment processing to avoid or to correct the problem. • Recommend a work-around which allows the Cospas-Sarsat System to continue to use the spacecraft, possibly in a degraded mode. • Determine that the problem is temporary and recommend that Ground Segment Providers remove that spacecraft from their tracking schedules until the problem resolves itself. • Determine that the spacecraft is no longer operational and remove it from the list of operational Cospas-Sarsat satellites. Whatever the action that is decided, the Space Segment Provider will notify the Ground Segment Providers of the on-going status of the spacecraft and of any actions that are recommended to address the issue. When the issue is resolved and the spacecraft returns to normal operation, the Space Segment Provider will notify the Ground Segment Providers, through another SIT 605 System status message from its associated MCC, of the resolution, and of the current status of the spacecraft. Once the spacecraft has been operating correctly for some period of time, the associated nodal MCC will then update the QMS display on the Cospas-Sarsat website to show the return to operational status. - END OF SECTION 5 - 6-1 6. FUNCTIONS OF AN MCC OPERATOR For an MCC to fulfil its obligations in the Cospas-Sarsat System, the MCC operator must be able to perform many functions. Many of the functions that are required of an MCC operator, including many of those functions listed in Annex G of C/S A.006, are described in the remainder of this chapter. These descriptions are all at a general level; the details will vary according to the equipment available and the procedures defined for the operation of any individual MCC. For specific details of how an MCC operator should perform any individual function on the available MCC equipment, the operator is referred to the equipment manuals that are supplied by the vendor of the equipment that is used in their MCC. Although the explanations below say that the MCC operator should perform many specific actions in the cases described, the actual performance of these actions may be delegated to others: • the MCC System Manager, • another operator who is familiar with the recommended action, • another person designated by the Ground Segment Provider Administration, • a contracted support person or organization. For each MCC, the local operational procedures should identify the appropriate person to take action in each situation. 6.1 Communications with SPOCs The MCC operator must be familiar with all of the SPOCs and RCCs that are served by this MCC, and with the means that are available to communicate with each of these facilities. For each SPOC or RCC, this may include any of the facilities described in the following paragraphs. The MCC operator must be able to communicate by voice with the destination facility. This means that the operator must have the necessary telephone numbers available. If the MCC employs a translation service to communicate with personnel at other facilities, then the MCC operator should be capable of using this translation service as needed. It is recommended that MCC operators have basic English language skills. The MCC operator must also be able to use any of the other means of communications that have been agreed with each SPOC or RCC, which may include facsimile (fax) or email. For each such link, the operator must have available the telephone number or email address of the destination facility. 6-2 Section 4.4 of this Handbook describes the data communications links that may be used in the Cospas-Sarsat data distribution system, and the interfaces that the MCCs have to support to use these communications links. These links may also be used to send narrative text messages to the personnel at the destination facility. For all of these communications links, the MCC operator must be able to use the communications equipment, both to send and to receive messages, and to generate and receive (and understand) the information in a language that is compatible with the personnel at the destination facility. When an incident alert message is to be sent to a destination facility, the MCC equipment will automatically format the alert data, typically as a SIT 185 message (as explained in section 4.5.3 of this Handbook) and send this message to the destination facility. However, the MCC operator must be able to provide any necessary support to the personnel at the SPOC or RCC. This may include: • Find the data associated with any specific incident alert, based on any of the information listed in section 3.10 (“Information Archival and Retrieval”) of the MCC specification (document C/S A.005). The search parameters will include the identification of the destination facility, and may also include one or more of: - the date and time, - the geographic location, - the beacon identifier or its country code, - the identification of the vessel on which the beacon is carried. • Find any specific message, based on any of the information listed in section 3.10 (“Information Archival and Retrieval”) of the MCC specification (document C/S A.005). The search may be based on the destination facility and the range of times. Alternately, it may be based on the direction of transmission (sent or received at the MCC) and any one of: - the date and time, - the SIT format number, - the source or destination of the message, - the beacon identifier or its country code, - the identification of the vessel on which the beacon is carried. The SPOC or RCC may ask for assistance interpreting the data in the incident alert message. For example, a SPOC may ask why a particular type of alert (an initial alert, a confirmation alert, a conflict alert, or a cancellation message) was generated and what this means for the beacon incident. The SAR personnel may also want to know more about the reliability or accuracy of any individual position estimate. While not required, it is helpful if the MCC operator is able to provide advice and assistance to the Search and Rescue personnel in response to all such inquiries. 6-3 In particular, it is valuable if the MCC operator is able to provide assistance regarding the data provided in the SIT 185 message, as described in section "Cospas-Sarsat Distress Messages" of document C/S G.007, “Handbook on Distress Alert Messages for Rescue Coordination Centres (RCCs), Search and Rescue Points of Contact (SPOCs) and IMO Ship Security Competent Authorities”, including position data that can be found in section “Summary Guidance on the use of position data in alert messages”. The incident alert messages that are sent to SPOCs are normally in the SIT 185 message format, unless the national Administration has selected a different format (such as WhatsApp). These messages are specified in the SID (document C/S A.002) and they are described in document C/S G.007 (RCC Handbook). They are not explained in this Handbook. However, many of the data items that are included in these SIT 185 messages are also used in other message formats and are described in various parts of this Handbook. The SAR personnel may also be interested in the coverage available for a specified area of interest; the coverage analysis described in section 6.13 of this Handbook addresses this type of inquiry. 6.2 Communications with other MCCs The MCC operator must also be aware of the other MCCs with which their MCC may have to communicate. For most non-nodal MCCs, this will be their nodal MCC. In addition: • The operator at a nodal MCC must be able to communicate with all of the other nodal MCCs and with any of the MCCs within their own DDR. • The operator of an MCC in the Central DDR must be able to communicate with all of the other MCCs in that DDR (including the nodal FMCC). • If any bilateral agreements exist with other MCCs, the operator must be able to communicate with those MCCs. In addition to these explicit communications requirements, it is advisable that an MCC operator should be able to communicate with any MCC whose Service Area is adjacent to their own Service Area. 6.2.1 General Communications As for the communications with the personnel at a SPOC, the MCC operator must be able to communicate by voice with the other MCC. This means that the operator must have the necessary telephone numbers available. If an MCC employs a translation service to communicate with personnel at other facilities, then the MCC operator should be capable of using this translation service as needed. The MCC operator must also be able to use any of the other means of communications that have been agreed with the other MCC, which may include facsimile (fax) or email. 6-4 For all of these communications links, the MCC operator must be able to use the communications equipment, both to send and to receive messages. 6.2.2 Narrative Messages A narrative message is essentially a message that contains a free-form block of text for the information of the operator at the receiving facility. It is formatted to the extent that it includes the header and trailer information that is necessary to route the SIT message through the data distribution system and that it is restricted to the character set defined in the SID (see section B.1 of this Handbook). Otherwise, the contents of the message can be laid out in any way that the operator desires. A more detailed description of the narrative message format is provided in section A.7.3 of this Handbook, and further information is available in section B.7 of this Handbook. These narrative messages are intended to be read by a human at the receiving facility; they are not designed for automated processing. The sample narrative message in Figure 6.1 is a test message that could be sent to request that the recipient acknowledge receipt of the message, to verify that the communications link has performed successfully. Additional samples are provided elsewhere in this document. Narrative messages are normally entered by the operator, using the capabilities provided by the computer system at the MCC. However, there are a few types of narrative message that may be generated automatically by the MCC computer. /00087 00000/7010/20 098 1404 /915/5030 / FROM: ARMCC TO: AUMCC THIS IS TEST MESSAGE FROM ARMCC TO AUMCC. PLEASE ACKNOWLEDGE BY DIRECT FTP VPN AND AFTN LINK. BEST REGARDS ARMCC OPERATOR. QQQQ /LASSIT /ENDMSG Figure 6.1: Sample Narrative Message This is a sample of a narrative message to verify the correct operation of the communications link between two MCCs. 6-5 6.2.3 System Status Messages A system status message should be used in any situation where the status of some part of the System has changed and the new status is likely to affect other MCCs. It is intended to be read by a human at the receiving facility; it is not designed for automated processing. Many system status messages are generated automatically by the MCC computer, to report on anomalies in the status of some component of the system, as detected by the MCC computer. However, a system status message may also be entered by the operator, using the capabilities provided by the computer system at the MCC. The sample system status message in Figure 6.2 is a routine message to notify all MCCs when an MCC is replaced by an operational backup. (More information about this kind of situation is provided in sections B.8 and D.1 of this Handbook.) Additional samples of system status messages are provided elsewhere in this document. FROM: FMCC TO: ALL MCCs SUBJECT: ITMCC BACKUP 1. ITMCC IS NOT OPERATIONAL FROM 0725 UTC DUE TO MAINTENANCE 2. THE FMCC HAS ASSUMED THE BACKUP AND DUTIES OF THE ITMCC AT 1200 UTC 3. MCCS ARE REQUESTED TO TRANSMIT ALL TRAFFIC FOR THE ITMCC TO FMCC. 4. CENTRAL DDR MCCS ARE INVITED TO CONFIRM RECEIPT OF THIS MESSAGE BY SENDING AN ACKNOLEDGE MESSAGE TO THE FMCC AFTER THE CONFIGURATION CHANGES ARE MADE. 5. ITMCC WILL INFORM WHEN IT RESUMES THE NORMAL OPERATIONS. 6. FMCC COMMUNICATION ADDRESSES: AFTN LFIAZSZX FAX: +33-561 274 878 PHONE: +33-561 254 382 BEST REGARDS FMCC Figure 6.2: Sample System Status Message This sample message shows the announcement of an MCC assuming the backup of a not operational MCC that is not a nodal MCC. 6.2.4 SIT Messages Embedded in Narrative Messages The Cospas-Sarsat System documents are generally intended to describe a System that is complete and coherent. That is, all parts of the System work together to meet the same specifications. However, in the real world, it is not always possible to maintain such a complete level of consistency. Some parts of the System may have been upgraded while other parts have remained at a previous level of operation. In such cases, it is often necessary to provide a work-around, to allow the two parts to continue to operate together during the interim period before all components of the System have achieved the full level of compatibility with the specifications. 6-6 One method that is used to allow such a level of inter-operability of components that are at different levels of implementation is to take a message that has been structured according to a newer SIT message format specification and to encapsulate it in a narrative message (SIT 915) format. This process is described in more detail in section D.5 of this Handbook. That section also explains some of the circumstances where this work-around is recommended. 6.3 Monitoring the System As noted in section 5.2.3 of this Handbook, an MCC operator must be able to monitor the MCC itself and the other parts of the Cospas-Sarsat System that are linked to it, to ensure that they are functioning correctly. Typically, a computer-based MCC will raise warnings and alarms to indicate any problems that need to be addressed. An MCC operator must be able to respond to any warnings or alarms raised by the MCC. Section 5.2.3 of this Handbook describes some of the checks that are recommended to enable the operator to verify the operation of the MCC and of the Cospas-Sarsat System. Some additional checks are described in the remainder of this section. In addition to this monitoring, the MCC operator should maintain a general awareness of the status of the System. 6.3.1 External Systems Monitoring The operator can verify the operation of external systems, including the communication links to them. The first step is to determine the time of the most recent communications on the links between the MCC and: • Each LUT associated with the MCC, • Each other MCC that communicates directly with the MCC, • Each RCC or SPOC that is supported by the MCC, In each case, if there have not been any recent communications, the operator should determine why this is the case. The most likely cause, of course, is that there has been no data to be sent. In this situation, the operator should initiate communication checks to verify that the communications link and the system at the other end of the link are performing as required. If, on the other hand, the lack of communications is due to a problem with the communications link or with the destination system, the operator should start an investigation to determine what the problem is and to resolve that problem. The communications link testing is described in more detail in section F.3 of this Handbook. 6-7 6.3.2 Reference Beacon Monitoring An MCC that is associated with an administration that is responsible for the operation of a system reference beacon should verify that the signals from the reference beacon are regularly detected and reported to the MCC. Many reference beacons are monitored under the provisions of the Cospas-Sarsat Quality Management System (QMS); however, even those reference beacons which are outside the scope of the QMS verification should be monitored by the operator of the beacon. If there are any anomalies in the data that is received from the beacon, then the associated MCC should report them to the other Ground Segment Providers and should investigate the cause of the anomaly, as necessary, and problems should be corrected. 6.4 MCC Backups Each MCC is a vital part of the Cospas-Sarsat data distribution system. Therefore, if any MCC fails, it is essential that the system be re-configured to ensure that the data distribution system remains intact, and that all incident alert messages will be distributed to the correct final destination. Document C/S P.011, “Cospas-Sarsat Programme Management Policy” and the MCC specification (document C/S A.005) place specific requirements on the time allowed to switch to the operational backup: “the capability of an MCC to continuously deliver alert messages shall not be interrupted for longer than one hour”. To ensure that this requirement is met, the MCC specification further requires that “all affected MCCs shall implement backup procedures within 30 minutes of notification”. Some Ground Segment Providers include a second set of MCC equipment as a part of their contribution to the data distribution network. If an MCC that has such an internal backup capability fails, then the MCC operator must be able to change to the internal backup capability quickly as soon as it may be required. This switch-over may be done directly by the MCC operator or it may be done by calling in support services. If the MCC cannot operate, and if the internal backup facility is not available (or not working), the MCC operator must then ask to be backed up by its backup MCC. Typically, such a request would be made by telephone; alternately, it could be done by sending a narrative message to the backup MCC. Once backed up by another MCC, the MCC operators (at both the failed MCC and the backup MCC) must know the local procedures to deal with beacon alert data sent. For example, the beacon alert data might be sent as SIT 185 messages by fax or other means from the backup MCC to a facility, identified in the backup plan, which can distribute alerts to the supported SPOCs. Alternately, the backup MCC may have to be re-configured to automatically distribute the data to the SPOCs and RCCs of the failed MCC. Whatever the arrangement, all beacon alert data received by the backup MCC must be forwarded (manually or automatically) to the responsible SPOC or RCC. 6-8 When an MCC is backed up, either by an internal facility or by another MCC, the backup MCC will send a SIT 605 message to inform all MCCs of the situation. (See the sample messages in Figure B.1, Figure B.2, and Figure B.3.) In most of these cases, most MCCs do not need to change any communications. Only those MCCs that are directly linked to the failed MCC will have to make changes, to ensure that the data is sent to the correct backup facility. However, the MCC operators must be aware of the impact of any MCC backups and be able to change communications as and when necessary. If a nodal MCC fails and is being backed up, the backup MCC will send a SIT 605 message to notify all MCCs of the failure and the backup arrangements that are in place. The operator of each associated MCC must change the configuration of their communications to ensure that all beacon alert data is sent directly to the nodal backup MCC. When the failed MCC is restored to full operational capability, it will send a SIT 605 status message to notify all MCCs of this change. (See the sample messages in Figure B.4 and Figure B.5.) At this time, the operators of all affected MCCs must restore their system to its normal operating configuration. A more comprehensive explanation of the backup requirements for an MCC is provided in section D.1 of this Handbook. 6.5 Communications Support The Cospas-Sarsat data distribution system is essentially a communications network; as such, the communications facilities in that network are absolutely necessary for the correct operation of that system. If any communications link fails, there has to be a quick and efficient method of maintaining the network while the failed component is repaired and brought back into service. The communications services that are described in the SID (document C/S A.002) and that are the primary means of data communications through the network are all basically reliable services that include their own internal routing capabilities to by-pass individual failures within the network. And each MCC is expected to maintain two separate communications links to any other MCC with which it communicates. However, it can still happen that an MCC is unable to successfully communicate with another MCC or with an RCC or SPOC. If a single communications link (e.g., FTP/VPN) is lost for all MCC communications, the MCC should send a narrative message (SIT 915) or a system status message (SIT 605) to notify other MCCs of the problem, and to request that they use the alternate communications link for all messages until the problem has been resolved. A sample of such a message is shown in Figure 6.3. In this example, because the AUMCC is a nodal MCC that communicates with many other MCCs, the message is sent as a system status message (SIT 605), so that all MCCs will be aware of the situation. 6-9 As another example, suppose that an MCC uses AFTN to communicate with a SPOC and has no alternate means of communication with that SPOC. In this case, if the AFTN fails, the MCC will not be able to send incident alert messages to that SPOC. When such a failure occurs (or more generally, when an MCC is not able to communicate with a SPOC by any designated means), the MCC should request another MCC (via a SIT 915 message, voice communications or other available means) to assume responsibilities to deliver messages to the affected destination, per previously agreed backup procedures. Such backup procedures may require that the assisting MCC perform a full backup of the failed MCC. Notification to other MCCs would be performed per the agreed backup procedure. While the backup is in place, the MCC should investigate the cause of the problem, and work to restore the normal communications as soon as possible. Once it is understood that the MCC has lost all communications facilities with another MCC, the MCC should request another MCC (via a SIT 915 message, voice communications or other available means) to assume responsibilities to deliver messages to affected destinations, per previously agreed backup procedures. Such backup procedures may require that the assisting MCC perform a full backup of the failed MCC. Notification to other MCCs would be performed per the agreed backup procedure. The sample message, in Figure 6.3, is a notification from the Australian MCC of a failure of its primary communications link (FTP/VPN), with a request that other MCCs use the alternate communications link (AFTN) in place of that failed link. /85324 00000/5030/20 138 0125 /605/5030 /FROM : AUMCC TO : ALL MCCS SUBJECT : COMMUNICATIONS FAILURE 1. FTP WITH THE AUMCC IS CURRENTLY UNAVAILABLE. 2. PLEASE CHANGE COMMUNICATIONS TO USE AFTN WITH AUMCC. SORRY FOR ANY INCONVENIENCE, AUMCC QQQQ /LASSIT /ENDMSG Figure 6.3: Sample Notification of Communications Failure This is a sample of a system status message that might be sent from an MCC to notify other MCCs of a failed communications link and to request that they implement the appropriate backup arrangements. 6-10 In the event of a complete failure of all communications services to an MCC, the MCC is effectively out of service, and the appropriate backup arrangements will be required. 6.6 Resending a Missing Message Every message from an MCC to a destination (MCC or RCC/SPOC) has a sequential message number. When a destination receives a message from an MCC, it should check that the message number is in sequence. If not in sequence, the destination knows that there is a problem with the messages sent from the MCC. For example, the AUMCC sends a message to the USMCC with message number 34267. If the previous message from the AUMCC to the USMCC was message number 34265, the USMCC operator knows that message 34266 from the AUMCC is missing. The USMCC operator should then investigate and may request the AUMCC that the missing message be re-transmitted. The resend request can be in a narrative message (as in Figure 6.4), or it may be a voice request over the telephone If an MCC receives a message that is out of sequence, then the operators of both MCCs (the originating MCC and the destination MCC) should coordinate to investigate the reason for this anomaly. There are a number of obvious possibilities: • A software failure in the originating MCC may have cause the wrong sequence number to be placed in the message. • A communications failure may have caused a previous message (or messages) to be lost or corrupted. This failure may have occurred in: - the communications interface in the transmitting MCC, - the communication network hardware or software, • A communications interface failure in the transmitting MCC may have caused the message number in the current received message to be corrupted. • A software failure in the receiving MCC may have caused the receiving MCC to incorrectly report an anomaly when the message was actually received in the correct sequence. Regardless of the cause of the problem, the MCC operators should ensure that any messages that have been missed will be sent again. If any message has been missed, the operator at the receiving MCC should request that the message be re-transmitted. The resend request can be in a narrative message (as in Figure 6.4), or it may be a voice request over the telephone. The key information that will be required by the originating MCC is the message number of the original message(s). 6-11 /81193 00000/5030/20 098 1326 /915/5630 /FROM: AUMCC TO: SIMCC SUBJ: MISSING MESSAGE PLEASE RESEND MESSAGE 41534 TO THE AUMCC. REGARDS AUMCC QQQQ /LASSIT /ENDMSG Figure 6.4: Sample Message Re-Transmission Request This is a sample of a narrative message that might be sent from an MCC to request that another MCC re-send a message that was not received in the expected sequence (possibly due to a failed communications link). The MCC operator(s) at the originating MCC must be able to find all of the original messages and have them re-transmitted to the appropriate destination. As specified in document C/S A.002, the message number field (MF \#10) contains two separate message numbers. The first number is the message sequence number that is computed when the message is formatted, and the second number is used to identify the original message number of a previously sent message. Figure 6.5 contains a sample of a message that has been re-transmitted, with the new message number in the first part of the MF \#10 and the original message number in the second part of MF \#10. 6-12 /09925 09922/2470/20 137 1418 FTP /915/2270 FM ITMCC TO FMCC SUBJECT: LEOLUT LOCATION ACCURACY CONFORMITY STATUS MESSAGE. IN ACCORDANCE WITH COSPAS SARSAT C/S A003 PARA 2.5.4.3 ITMCC HAS RESUMED THE DISTRIBUTION OF DOPPLER SOLUTION DATA FOR COMBINATION LEOLUT 2471 AND SATELLITE S13. BEST REGARDS ITMCC QQQQ /LASSIT /ENDMSG Figure 6.5: Sample Re-Transmitted Message This is a message that has been re-transmitted, with the message number field containing both the original message number and the new message number. 6.7 Suppressing Beacon Alerts Following the rules specified in the Cospas-Sarsat Data Distribution Plan (the DDP, C/S A.001), an MCC will normally send every incident alert that it receives to the appropriate destination, whether that destination is another MCC or a SPOC or RCC. However, that destination may not wish to continue receiving such alert messages indefinitely. The MCC Operator shall be able to suppress (or enable) alert data transmission for a particular beacon when requested to do so by an alert data recipient. There are many reasons why an alert data recipient may wish to suppress the reception of alert messages from a particular beacon, such as: • The beacon activation has been determined to be a false alert, and no distress incident is taking place. • The beacon has been located and rescue personnel have contacted the person(s) in distress; no further information is required from the Cospas-Sarsat System. • The beacon has been located and the person(s) in distress have been rescued, but it was not possible to recover the beacon and turn it off. • The beacon is being used for a test, and no distress incident is involved. • A test is planned; again, there will be no distress involved. 6-13 In any of these situations, and especially when the MCC (or SPOC) is busy with other distress incidents, they may not wish to be distracted by reports from a beacon that is not involved in a real emergency. After a beacon has been identified for suppression of alerts, it may become necessary to resume the transmission of those alerts. For example: • A beacon that had been located may be lost. If the weather has turned bad, or if the wind has risen at sea, the beacon may not be in the same location, or it may not be easy for the rescue personnel to find. • A search aircraft that located the beacon may have run low on fuel and have to return to its base before the rescue can be continued. • The conductors of a test may wish to receive more data about the test beacon(s) from the MCC. In any of these (or similar) situations, the beacon is marked for transmission. In all of these cases, the MCC that is requesting the suppression or transmission of incident alert messages sends a message to the other MCCs to notify them of the situation, and to request the appropriate action. Depending on the situation, and the number of MCCs to whom the request has to be sent, this may be done in a narrative (SIT 915) or a system status (SIT 605) message. The narrative message in Figure 6.6 is an example of a message that might be sent to notify another MCC when it does not want to receive any more incident alert messages for a specified beacon. In this case, as explained in the message, the alert has been confirmed as a false alert. 6-14 /00460 00000/4770/20 099 0255 /915/5030 / FROM: HKMCC TO: AUMCC SUBJECT: SUPPRESSING SIT 915 MEOSAR ALERT MSGS TO THE HKMCC AUMCC REF NO : 74948 HEX ID : 3384E502C2FFBFF COUNTRY : 412/CHINA THE HKMCC WOULD LIKE TO ASK FOR THE AUMCC TO SUPPRESS THE CONTINUOUS TRANSMISSION OF ALERT MESSAGES FOR THE ABOVE BEACON ACTIVATION TO THE HKMCC. THE ALERT WAS CONFIRMED AS FALSE ALERT. THANK YOU FOR COOPERATION REGARDS, HKMCC OP QQQQ /LASSIT /ENDMSG Figure 6.6: Sample Message to Request Suppression of Beacon Alerts This is a sample of a narrative message that might be sent from an MCC to notify another MCC that it no longer wishes to receive alert data from the specified beacon. Figure 6.7 then shows the response, which acknowledges the request and confirms that the transmission of alerts for the specified beacon will no longer be sent to the MCC that had requested suppression of the alerts in Figure 6.6. /75821 00000/5030/20 099 0302 /915/4770 /FROM: AUMCC TO: HKMCC SUBJECT: HEX ID 3384E502C2FFBFF THE ABOVE BEACON HAS BEEN SUPRESSED TO THE HKMCC REGUARDS AUMCC QQQQ /LASSIT /ENDMSG Figure 6.7: Sample Message to Confirm Suppression of Beacon Alerts This sample narrative message shows the response to the request in Figure 6.6. 6-15 An MCC operator may also request that the continued transmission of alerts be resumed for a beacon, by sending a system status message to identify the beacon and to notify all MCCs that this continued transmission is desired. 6.8 Quality Management System Messages Document C/S P.015, “Cospas-Sarsat Quality Manual”, describes the Quality Management System (QMS) that is used to ensure that the System maintains the quality standards that are essential to such a critical operation. The data distribution system is required to support the exchange of messages in support of the QMS: • Alert data for designated reference beacons is sent by all MCCs to their associated nodal MCC, in the format defined in documents C/S A.002 and C/S A.003, as explained in ANNEX B of this Handbook. This process is specified in the DDP (document C/S A.001) and explained in ANNEX A of this Handbook. The format that is normally expected for that type of data, as defined in the SID (document C/S A.002) and as explained in ANNEX B of this Handbook, is used to transmit this QMS data. • Each nodal MCC updates the status pages on the Cospas-Sarsat web site to inform all MCCs (and the Secretariat and other interested organizations) of the current status of the system in its DDR. As of 2023, this is done manually. As a system enhancement, nodal MCCs will have the capability doing this by sending an XML file to the QMS Automated Reporting System (QARS), as described in Annex J (“QMS Automated Reporting System”) of document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”. The format of the XML file is described in section J.2 (“XML Format for QMS and Space Segment Status Report”) in Annex J of C/S A.003. • The nodal MCC notifies any Ground Segment Provider whose contribution to the Cospas- Sarsat Ground Segment is not meeting the relevant criteria. This is done by sending a narrative (SIT 915) message to the MCC of that Ground Segment Provider. Section B.8.5 of this Handbook contains examples of such notification messages. • The nodal MCC notifies any Space Segment Provider whose contribution to the Cospas- Sarsat Space Segment is not meeting the relevant criteria. This is done by sending a narrative (SIT 915) message to the MCC of that Space Segment Provider. The format of such a notification message will be similar to the format used to notify a Ground Segment Provider, as illustrated in the examples in section B.8.5 of this Handbook. • The MCC of the Space Segment Provider sends a system status message to all MCCs to inform them of the updated status of the equipment. A standard message format for this notification is provided in Figure 5-4 (“Standard Message for Reporting a Spacecraft Anomaly”) in section 5.2 (“Status of Space Segment”) of the DDP (document C/S A.001). • The nodal MCC requests the MCC of a Ground Segment Provider to investigate an identified issue when the relevant QMS criteria are not met. This is done by sending a 6-16 SIT 915 narrative message to the MCC associated with the failed equipment or a SIT 605 message to all MCCs. The templates for these messages are listed in Table in this Handbook. • The nodal MCC notifies all MCCs when data from a particular component (or combination of components) is being suppressed because it does not meet the required standards. A system status message (SIT 605), such as the sample message shown in Figure B.13, is used to send this notification. This message also requests that the MCC associated with the failed equipment suppress associated (Doppler or DOA) position data. • If a SIT 605 message was sent for a failed component, the nodal MCC notifies all Ground Segment Providers when the failure has been resolved, and, as relevant, that data from that component (or from a combination that includes that component) can now be distributed through the System again. Another system status message (SIT 605), such as the sample message shown in Figure B.14, is used to send this notification. An MCC operator should be aware of the current status of the Cospas-Sarsat System at all times. This is done by observing the system status and narrative messages that are received at their MCC. The operator can also check the current status of the System by looking at the status pages on the Cospas-Sarsat web site: • On the professional web sub-site, select the tab and then click on under . • Scroll through the status tables on the display. • Alternately, request a specific status display: - Select the Quality Monitoring System type, - Select the DDR. • Review the status of the selected item. The page also allows the operator to select the option to export the display in a printable format, to a printer or to a Portable Document Format (.pdf) file. Figure 6.8 contains an example of the display that is available from this web page. 6-17 Figure 6.8: Sample QMS Status Display This is a sample of the System status display (retrieved in printable format) that is available on the Cospas-Sarsat web site. 6.9 Beacon Registration Requests When an incident alert message is received at an RCC or SPOC, the SAR technicians there will usually want as much information as possible about the distress beacon that initiated the alert. A major source of such information is the beacon registry, where the beacon should have been registered. A request for beacon registration information may occur as follows: • The RCC or SPOC asks the destination MCC, from which they received the incident alert, for more information about this beacon. This may be a digital message, or it may be a verbal request by telephone. (Note that the alert message sent to the RCC or SPOC may contain: ![Image 1 from page 115](/images/cospas-sarsat/G-series/G010/G010_page_115_img_1.png) 6-18 o relevant beacon registration information, if the MCC has registration information for the subject beacon ID, or o relevant beacon registry point of contact information, enabling the RCC or SPOC to request registration information directly from the registry administrator or, if beacons for the associated country code are registered in the C/S International Beacon Registration Database (IBRD), enabling the RCC or SPOC to retrieve registration information directly from the IBRD. • The destination MCC retrieves the country code from the beacon message and identifies the supporting MCC, in whose Service Area that country is. • The destination MCC sends a request (in a narrative message) to the supporting MCC. o If the destination MCC is also the supporting MCC, this step is not required. o If beacons for the associated country code are registered in the Cospas-Sarsat International Beacon Registration Database (IBRD), the destination MCC may retrieve the registration information directly from the IBRD. • The supporting MCC requests the beacon registration data from the country of registration. The request must specify the beacon identifier: - A fifteen-character hexadecimal identifier for a first-generation beacon (FGB) or a second-generation beacon (SGB), - A twenty-three-character hexadecimal identifier for an SGB. This may be in the form of a data retrieval request directly to the beacon registration database, a narrative message or a voice request to the holder of the registry, or any other form that is acceptable to both parties to this exchange. • The beacon register returns the information about the beacon. • If the beacon is not registered, then this information is returned to the requesting party, usually in the form of a narrative message. • If the beacon is registered, then the supporting MCC sends the information from the register to the destination MCC, formatted into a SIT 925 message as defined in the SID (document C/S A.002). • The message is sent to the requesting agency (RCC or SPOC). This process is straightforward. However, there are exceptions. The beacon may have been registered in the wrong database. This is not supposed to happen, but it does occur occasionally. The MCC operator with some experience in the region may know of another country that might hold this data, and re-direct the request to that country’s registry. If the request does find the beacon, then the process can continue as above. When a beacon design is type-approved, some information that will apply to every beacon that is built to that design is recorded on the Type-Approval Certificate (TAC). For an SGB, that 6-19 information is stored in a database by the Secretariat; it is also sent to all MCCs (in a SIT 927 message). Each MCC maintains its own internal database of SGB TAC information, which it updates each time it receives new information. The MCC can then retrieve that data and include it in a SIT 985 message that is sent automatically with the incident alert message. Figure 6.9 contains a sample narrative message that requests the beacon registration data for the beacon whose identifier is specified in the message. /51029 00000/2270/20 110 0542 /915/5030 /FM FMCC COSPAS-SARSAT TOULOUSE TO AUMCC FMCC REF NO 173065 HEXACODE (BEACON ID) : 3EF4957FBF81FE0 REF 406 BEACON : 76543, COUNTRY : 503/AUSTRALIA LAT:06 57.7S, LONG:065 48.3E A 406MHZ DISTRESS BEACON HAS BEEN LOCATED IN FMCC SERVICE AREA. PLEASE SEND US AVAILABLE REGISTRATION INFORMATION FOR THIS BEACON ID THANKS FOR COOPERATION. FMCC. QQQQ /LASSIT /ENDMSG Figure 6.9: Sample Message to Request Beacon Registration Data This is a sample of a narrative message that might be sent to an MCC to request the information held in the beacon registry of the nation whose country code is encoded in the beacon identifier. 6-20 /71472 00000/3660/20 100 0657 /925/5030 /3EF4957FBF81FE0 / BEACON ID: 2DC4000000FFBFF **** BEACON REGISTRATION DATABASE INFORMATION **** OWNER: ANONYMOUS OWNER 1234 LOCAL DRIVE TEL 1: HOME 0123456789 HOME CITY CA TEL 2: WORK 1234567890 98765 USA TEL 3: EMAIL: CONTACTS: JOHN DOE JANE DOE TEL 1: HOME 0123456789 TEL 1: HOME 0123456789 TEL 2: TEL 2: WORK 1234567890 VESSEL NAME: SUNKEN TYPE: SAIL 1 Masts LENGTH OVERALL (FT): 36 COLOR: BLUE/WHITE CAPACITY: 8 RADIO CALL SIGN: REGISTRATION NO: CF12345P RADIO EQP: VHF INMARSAT NUMBER: CELLULAR NUMBER: 2345678901 NUMBER OF LIFE BOATS: 0 NUMBER OF LIFE RAFTS: 0 HOME PORT PRIMARY SRR: PACAREA SECONDARY SRR: HOME PORT: MARINA NAME SAN FRANCISCO CA MANUFACTURER: XXX MODEL NUMBER: ABC-12 ACTIVATION TYPE: CAT2 (MANUAL) BEACON CONTAINS SVDR: NO DATE FIRST REGISTERED: 02 JUN 1999 DATE REG EXPIRES: 02 JUN 2001 DATE LAST UPDATED: 02 MAY 2001 REMARKS: SPECIAL STATUS: SPECIAL STATUS DATE: SPECIAL STATUS INFO: QQQQ /LASSIT /ENDMSG Figure 6.10: Sample Message to Report Beacon Registration Data This is a sample of a beacon registration data message that might be sent from an MCC in response to a request for beacon registration information. The details of exactly what registration data is available will depend on the beacon registry and the data that was entered by the beacon owner. Figure 6.10 contains the response to that request: the information that was retrieved from the beacon register entry for that beacon. Figure 6.11 shows a different response: a narrative message to say that the beacon was not registered. However, it does provide some information about previous detections of the same beacon. See also “Sample Message for SIT 925” and “Sample Message for SIT 985 SGB Characteristics Based on TAC Number” in document C/S A.002. 6-21 /85498 00000/5030/20 110 0600 /915/2270 /3EF4957FBF81FE0 /FROM: AUMCC TO: FMCC SUBJECT: BEACON WITH HEX 3EF4957FBF81FE0 PLEASE SEE BELOW INFORMATION FROM JRCC AUSTRALIA REGARDING BEACON WITH HEX ID 3EF4957FBF81FE0 REGARDS AUMCC OPERATOR SUBJ: BEACON HEX ID: 3EF4957FBF81FE0 INCIDENT: 2020/2703 1. JRCC AUSTRALIA HAS CHECKED OUR REGISTRATION DATABASE FOR AUSTRALIAN CODED BEACON HEX ID 3EF4957FBF81FE0 AND IT IS UNREGISTERED. 2. THIS BEACON HAS BEEN DETECTED IN THE SEYCHELLES ON TWO PREVIOUS OCCASIONS, 0N 05MAR20 AND 10APR20. 3. THIS ADVICE HAS ALSO BEEN CONVEYED BY EMAIL TO MRCC PORT BLAIR AND IDMCC 4. WE ARE UNABLE TO PROVIDE ANY FURTHER INFORMATION ON THIS BEACON BEST REGARDS, JRCC AUSTRALIA QQQQ /LASSIT /ENDMSG Figure 6.11: Sample Message to Report No Beacon Registration Data This is a sample of a narrative message that might be sent from an MCC to indicate that no registration data is available, in response to a request for beacon registration information. 6.10 System Data Updates As explained in section 4.3.5 of this Handbook, the satellite orbital elements and the spacecraft calibration data are included in the System Data that is distributed through the MCC network. The satellite orbital elements define the orbital path that the satellite follows around the Earth. They are essential to the solution processing that produces the independent (Doppler or Difference of Arrival) locations in the LEOSAR and MEOSAR systems, respectively. Although they are not essential for the GEOSAR processing, some GEOLUTs use the GEOSAR satellite orbital elements to improve the accuracy of the frequency measurements for each beacon signal that is received. 6-22 The satellite orbital elements are also used to determine the satellite footprint, for use in the validation of the location data received by the MCC. See section A.6.6 of this Handbook for a more comprehensive explanation of the satellite footprint validation. To support this footprint check, each MCC should maintain a copy of every set of satellite orbital elements, whether or not it has an associated LUT that may require that data. The following sections describe the distribution of the System Data through the Cospas-Sarsat data distribution system. However, in many cases, this data is also available from other sources. Table 6-1 contains a list of web sites that maintain current orbital elements for many of the satellites that comprise the Cospas-Sarsat Space Segment. Table 6-1 – Sources of Satellite Orbit Data The web sites listed in this table provide orbital elements for the satellites of the Cospas-Sarsat Space Segment. Title Link Comments Celestrak 1 https://www.celestrak.com/NORAD/elements/ Most of the Space Segment European GNSS Service Centre (GSC) 2 https://www.gsc-europa.eu/system-service- status/constellation-information Galileo satellite data Notes: (1) An independent (non-Government agency) web site. (2) Operated by the European Global Navigation Satellite Systems Agency. 6.10.1 LEOSAR Orbital Elements The orbital elements for each LEOSAR satellite are distributed through the MCC network to all MCCs regularly, typically every business day, by each of the Space Segment Providers. These elements are distributed as position and velocity vectors, in SIT 215 and SIT 216 messages. While these messages are normally sent in a SIT 215 format, the SIT 216 message format is used to send a new set of elements after each satellite manoeuvre. The distribution procedures for these orbital elements are explained in section A.7.2 of this Handbook. The message formats are explained in section B.6.1 of this Handbook. Since LEOLUTs are required to maintain orbit data internally (except during the period immediately after a satellite manoeuvre), using the measurements of the satellite downlink carrier frequency and the data received from designated system reference beacons, the data from the Space Segment Providers is usually not essential to the successful operation of the LEOLUT. However, it does provide a reference that is used to verify the orbit data that is used by the LUTs. Each time it receives a new set of orbital elements, the MCC is required to compare these elements to the 6-23 validated data that it already has, either from the MCC associated with the Space Segment Provider or from its associated LEOLUT. The criteria for matching the orbital elements are defined individually for each MCC. The action that is taken as a result of this comparison will depend on the desires of the Ground Segment Provider, as expressed in the configuration of the MCC: • If the new data matches the MCC data, then no action is required. The MCC and associated LEOLUTs can continue to use the data that they already have. • If the new data does not match the MCC data, then the MCC operator is notified, and should follow the MCC’s internal procedure to decide whether or not to accept the new data. The decision about sending MCC orbit vectors to an associated LEOLUT should take into account the accuracy of Doppler solutions generated by the LEOLUT for the associated satellite (and further discussed below) and the fact that the installation of new orbital element data may cause the loss of the calculated orbital history in some LEOLUTs. As reflected in the MCC’s internal procedure, the decision to use new orbital data should consider the quality of the solutions that have been generated by this LEOLUT using beacon messages relayed through the spacecraft in question (as determined, for example, by the QMS validation done by the nodal MCC): • If the solution data generated by this LEOLUT – satellite combination (since the satellite was last manoeuvred) has been accurate, then the existing elements are reasonably good, and the new elements may safely be rejected. • If the solution data generated by this LEOLUT – satellite combination has been of dubious quality, then the existing elements may not be good, and the new elements may be accepted and installed. In either case, the MCC operator is advised to check with the MCC associated with the Space Segment Provider to confirm that the new elements are valid. A sample of a SIT 215 message is available in Annex C of the SID. The format of the SIT 216 message is the same as that of a SIT 215 message; the only difference is the value in the SIT number field (MF \#4). 6.10.2 MEOSAR Orbital Elements The spacecraft that are used in the MEOSAR Space Segment are all satellites whose primary mission is a Global Navigation Satellite System (GNSS). In support of that mission, these satellites transmit their orbital data in the navigation downlink signals. Some MEOLUTs are designed to retrieve the precise orbital elements for the MEOSAR satellites from this navigation signal to generate accurate DOA position data. MEOSAR satellite orbital elements are distributed by the MCC associated with the Space Segment Provider in the SIT 217 messages, using the Two-Line Element (TLE) format described in section 6-24 C.3 of this Handbook. This orbital data is used by the MCC to validate DOA and encoded position data generated from MEOSAR satellite data. 6.10.3 GEOSAR Orbital Elements The GEOSAR satellites are stationary with respect to the surface of the Earth. Each GEOLUT is configured to receive the data from one satellite, so it is not essential that the GEOLUT have orbital elements for the detection and processing of the beacon data. There is no provision to distribute GEOSAR satellite orbital elements through the Cospas-Sarsat data distribution system. However, the measurement of the frequency of the signals received from a beacon will be slightly affected by the small relative motion of the satellite. Therefore, to achieve the desired frequency measurement accuracy, some GEOLUTs do retrieve the satellite orbit data (from the web sites listed in Table 6-1) and use that data to correct the measured frequency. 6.10.4 LEOSAR SARP Calibration The Search and Rescue Processor (SARP) instruments on the LEOSAR Sarsat spacecraft, which are supplied by the French Centre National d’Etudes Spatiales (CNES) as the Space Segment Provider, measure the time and frequency when each beacon message is received at the satellite. The data from the SARP instruments on the Sarsat spacecraft is encoded using data from the Ultra- Stable Oscillator (USO) in the SARP. To decode that data, each LEOLUT requires information about the SARP: • the precise frequency of the USO, • the time of a recent rollover of the time counter in the SARP (at which the time counter had a value of 0). This information can be computed from the data collected from the time calibration reference beacon, which is also operated by CNES. To ensure that the Ground Segment always has reliable SARP calibration data, this information is computed by CNES, and is distributed on a weekly basis through the French MCC (FMCC) to all Ground Segment Operators in SIT 415 (for SARP-2 instruments) and SIT 417 (for SARP-3 instruments) System Data Messages. The formats of these messages are described in more detail in section B.6.2 of this Handbook. Many LUTs can compute this SARP calibration data directly from the data that they receive from the CNES reference beacon. This enables them to operate independently of the data distributed by the FMCC. It should be noted that this applies only to the LEOSAR Sarsat spacecraft. The SARP instruments on the LEOSAR Cospas spacecraft encode the time measurements as Moscow Standard Time, and the frequency as a real value, so that no interpretation is required to compute the actual time and 6-25 frequency measurements reported by the Cospas SAR instruments. Time calibration is not required for processing SAR incident data from Cospas spacecraft. When an MCC receives a SARP Calibration message, it should validate the calibration data and then forward it to its associated LEOLUTs. Each LEOLUT may then use this data to validate its own calibration, and to update it as necessary. If the SARP calibration data that is received does not match the data that is already available in the MCC, this anomaly is reported to the operator, who should follow the MCC’s internal procedure to determine which data is valid for future use. Normally, if the LEOLUT has been producing accurate solutions for beacons relayed through this spacecraft, the calibration data that has been used is probably valid. In accordance with the section entitled “Reactivation of the SARP Instrument” in document C/S A.001, when notification about new SARP TCAL data is received by the MCC (following deactivation of the SARP instrument), the MCC Operator should follow the MCC’s internal procedure to: a) Ensure that the calibration time in the new SARP TCAL data is treated as valid in the MCC, without regard to previous SARP TCAL data; b) Validate the USO frequency per normal procedures; c) Ensure that the new SARP TCAL data (validated as noted above) is used to initialize the SARP TCAL data in associated LEOLUTs, without regard to previous SARP TCAL data; and d) Ensure that all Doppler solutions generated by associated LEOLUT(s) that contain SARP data for the associated satellite are filtered, until new SARP TCAL data has been loaded into the associated LEOLUT(s). Samples of a SIT 415 message and a SIT 417 message are available in Annex C of the SID. 6.10.5 LEOSAR SARR Calibration The Search and Rescue Repeater (SARR) instruments on the LEOSAR Sarsat spacecraft, which are supplied by the Canadian Department of National Defence (DND), as the Space Segment Provider, relay each beacon message received at the satellite to the LEOLUTs on the ground. The data from the SARR instruments on the Sarsat spacecraft is shifted in frequency by the oscillator in the SARR. When the SARR data is used in combination with the data from the SARP instrument to generate Doppler position data, it is essential that the frequency is measured accurately. To ensure that the frequency reported in the LEOLUT solution data is correct, the frequency received when known reference beacon signals are relayed through the instrument is measured, and the exact frequency offset generated in the SARR is measured. The Canadian Technical Evaluation Centre (CTEC) performs these measurements and distributes the frequency offset values through the Canadian Mission Control Centre (CMCC) and the MCC network in the 6-26 SIT 510 message. The format of this message are described in more detail in section B.6.3 of this Handbook. A sample of a SIT 510 message is available in Annex C of the SID. As indicated in the Table “System Information Messages” in document C/S A.001, few MCCs process the SIT 510 message. As long as there is a suitable reference beacon within the local coverage area of the LEOLUT, these computations can also be done in the LEOLUT. In this case, the LEOLUT can continue to operate independently of the data received from the CMCC. It should also be noted that a LEOLUT that does not perform the combined SARP-SARR processing does not require this calibration data for the accuracy of its independent Doppler location solutions. However, without this calibration data, the accuracy of the beacon frequency that is reported in the incident alert messages may not be accurate. When an MCC receives a SARR Calibration message, it should validate the calibration data and then forward it to its associated LEOLUTs as needed, per national procedures. Each LEOLUT may then use this data to validate its own calibration, and to update it as necessary. If the SARR calibration data that is received does not match the data that is already available in the MCC, this anomaly is reported to the operator, who should follow the MCC’s internal procedure to determine which data is valid for future use. Normally, if the Doppler position data is accurate in the combined SARP-SARR solutions that have been produced by this LEOLUT for beacons relayed through this spacecraft, the calibration data that has been used is valid. 6.10.6 MEOSAR SARR Calibration The Difference of Arrival (DOA) calculations that are performed in a MEOLUT to compute the independent location of each beacon that it detects depend on the accuracy of the measurements of the time and frequency when the beacon signals arrive at each satellite in the MEOSAR constellation. To provide sufficiently accurate time and frequency measurements for the computation of DOA position data in a MEOLUT, each MEOLUT uses one or more of the MEOLUT reference beacons that are visible to the satellites that it tracks to calibrate the data that it receives and processes. Because of the wide area of view of a MEOSAR satellite, it is not necessary that each MEOLUT operator have a separate reference beacon. Instead, a network of MEOSAR reference beacons is available, operated by various Ground Segment Providers who wish to support the MEOSAR system. These beacons are identified and specified in document C/S T.022, “Cospas-Sarsat MEOSAR Reference Beacon Network Design Guidelines”. Since each MEOLUT can calibrate its own time and frequency measurements, there is no need for the distribution of MEOSAR calibration data through the MCC network. 6-27 6.10.7 GEOSAR SARR Calibration A GEOLUT is required to compute the transmit frequency to an accuracy of 2 Hz or better for each beacon that is detected and reported to its associated MCC. Since there is a possibility that the frequency will be modified by the Doppler effect as the signal travels to and from the satellite, and again as the signal travels through the GEOSAR spacecraft and the GEOLUT receive equipment, it is necessary to calibrate the measured frequency data before it can be processed and reported in an incident alert message. Since each GEOSAR satellite can see almost one-third of the Earth’s surface, every GEOLUT always has at least one reference beacon visible to it. The transmit frequency of each reference beacons is well known and may be published in documents C/S T.006, “Cospas-Sarsat Orbitography Network Specification” or C/S T.022, “Cospas-Sarsat MEOSAR Reference Beacon Network Design Guidelines”. The status of each MEOSAR reference beacon is also available on the Cospas-Sarsat web site, under the tab. So one or more of these beacons can be used in the GEOLUT to calibrate its frequency measurements. Since each GEOLUT can calibrate its own frequency measurements, there is no need for the distribution of GEOSAR calibration data through the MCC network. 6.11 Satellite Manoeuvres Each of the spacecraft in the Cospas-Sarsat Space Segment is a satellite that is in orbit around the Earth. Many of these satellites are in stable orbits; once they are in the orbit, they automatically continue in the orbit without any further attention from the controllers on the ground. However, in order to maintain the desired orbit, some of the LEOSAR satellites must be manoeuvred at intervals. The satellite manoeuvres are generally small adjustments, made by firing a small rocket to move the satellite to the desired orbital position or direction. There are two different types of manoeuvre that may be applied to the LEOSAR satellites: • An in-plane manoeuvre adjusts the direction or speed of the satellite in the same orbit plane. The effect of an in-plane manoeuvre on the Doppler location processing increases as time passes. • An out-of-plane manoeuvre changes the plane of the satellite orbit. The effect of an out- of-plane manoeuvre is limited; it does not change significantly with the passage of time. The procedures to be followed when a LEOSAR satellite manoeuvre is planned are described in section 3.6.5 (“Scheduled Satellite Manoeuvres”) of the DDP (document C/S A.001). One MCC (associated with or designated by the Space Segment Provider) is responsible to notify the other 6-28 Ground Segment Providers of the plans for any manoeuvre. This notification will be provided to all MCCs through a system status (SIT 605) message (see Figure 6.12): • If the expected effect of the manoeuvre on the Doppler locations that are produced with data from this satellite is small (less than 2 kilometres impact within 24 hours), no further action is required at the MCC or at the LEOLUT. • For a manoeuvre that is expected to change the Doppler location by more than 2 kilometres within 24 hours after the manoeuvre, the MCC shall be configured to: o treat orbit ephemeris data received in a SIT 216 message within 24 hours after the end of the manoeuvre as valid, if they are within the maximum tolerance specified for the satellite in the associated System status message; and o use the validated SIT 216 orbit ephemeris data to immediately initialize orbit vectors at the MCC and its associated LUTs; • For a manoeuvre that is expected to change the Doppler location by more than 10 kilometres within 24 hours after the manoeuvre, then the associated MCC shall be configured to provide warning information on alert messages sent to SPOCs and RCCs about the potential error in Doppler location data for that satellite. This warning should continue until 24 hours after the end of the scheduled manoeuvre. The MCC should have an internal procedure to ensure that the MCC is properly configured to handle satellite manoeuvres, as described above (and in the section titled “Scheduled Satellite Manoeuvres” in document C/S A.001). The MCC operator should be capable of executing this procedure, as required nationally. At a minimum, the MCC operator is required to recognize SIT 605 messages regarding satellite manoeuvres and to ensure that appropriate MCC support personnel are notified. If the MCC has not received any new orbital elements for this satellite within 24 hours of the manoeuvre, the MCC operator should make inquiries of the responsible MCC to get the new orbit data for their LEOLUTs. In addition, MEOSAR satellites may be manoeuvred. Based on notification provided by the responsible MCC, MCCs may need to adjust the MCC orbital data validation thresholds for the satellite temporarily and take action to remove the satellite from the associated MEOLUT(s) schedule temporarily. Per MCC internal procedures, the MCC operator may not do the above tasks directly, but may instead report the manoeuvre to the MCC support personnel to ensure that the appropriate action is taken. 6-29 /12345 00000/3660/05 123 1412 /605/5030 /TO: ALL MCCS FROM: SUBJECT: MANOEUVRE OF SATELLITE STATUS OF MANOEUVRE: TYPE OF MANOEUVRE: 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 6.12: Sample Message to Announce a LEOSAR Satellite Manoeuvre This is a template for a system status message to be sent by the responsible MCC to announce a planned LEOSAR satellite manoeuvre. 6-30 Figure 6.12 is a copy of Figure 5.2 (“Standard Message for Reporting Satellite Manoeuvres”) from the DDP (document C/S A.001); it contains a template for the system status message (SIT 605) that should be sent by the responsible MCC to announce a LEOSAR satellite manoeuvre. 6.12 Satellite Outages The individual spacecraft that comprise the Cospas-Sarsat Space Segment are all designed for other primary missions, and are used as satellites of opportunity to carry the Search and Rescue instruments, the Search and Rescue Processor (SARP) and the Search and Rescue Repeater (SARR), that are described in section 3.4 of this Handbook. Because the SAR mission is not the primary purpose of the spacecraft, if any component fails, the spacecraft may not be repaired or replaced; instead, it may continue to operate in a degraded mode. Spacecraft anomalies and failures may be detected and reported through various channels, as explained in section 5.3.4 of this Handbook. As explained in that section, any spacecraft anomaly is reported to all MCCs of the Cospas-Sarsat Ground Segment in a system status message. If a SIT 605 is received saying that a satellite is completely out of service, the MCC operator should follow local procedures to remove that satellite from its LUT tracking schedules, and the MCC should filter any data from that satellite in the future. If the SIT 605 message indicates that the spacecraft is continuing to operate in a degraded mode, the situation is more complex. If the problem cannot be resolved, then it may be necessary to modify the Ground Segment to work around the problem. This may be a temporary solution, recommended in a system status (SIT 605) message, until the problem can be resolved in the Space Segment. Alternately, if a problem cannot be solved in the Space Segment, the revised ground segment processing may become a permanent solution. While this is temporarily defined in the system status message, it will eventually be reviewed by the Cospas-Sarsat Joint Committee and approved by the Council as an amendment to the appropriate System document. When an MCC operator receives a system status message that proposes a modification to the Ground Segment processing of data from a degraded satellite, they must take the appropriate action to implement the requested change. Several actions are possible at this point: • If the modification can be implemented by a change in operating procedures at the LUT or MCC, the appropriate procedure documents at the MCC (and/or LUTs) must be updated to show the new procedures. The new procedures should be implemented as soon as possible, or as specified by the Space Segment Provider. • If the modification can be implemented by a change to the national ground segment configuration, the MCC or LUT should be updated and the new configuration recorded in the appropriate national documents. (This is necessary to ensure that the modified 6-31 configuration is not removed at a later time by someone who was not aware of the revised requirement.) • If the modification requires a change to the equipment or software at the LUT or MCC, the change should be scheduled. If any contractual arrangements are required to implement the change, the appropriate person(s) should be notified, so that the specifications and contractual documents can be prepared, as necessary. • If the modification is expected to be a long-term change that will be raised and discussed at the Cospas-Sarsat Joint Committee (JC), then the national representative to Cospas- Sarsat and the Head of Delegation to the JC meeting (if that person has been identified) should be notified. They should also be informed of any immediate (or foreseen) consequences of the proposed modification. Depending on the nature of the proposed modification, more than one of these actions may be necessary. In each case, the action may be taken by the MCC operator, or the MCC operator may inform the MCC System Manager, who can then perform the action or ensure that the action is followed through. 6.13 Coverage Analysis An RCC may ask for information about the satellite coverage available to assist with the planning of SAR operations. While not an MCC operator requirement, an MCC operator may provide information on satellite coverage availability, based on tools available at the specific MCC. Note that SIT 185 messages provide information about LEOSAR satellite visibility (in Message Field \#29, titled “NEXT TIME OF VISIBILITY”), based on optional LEOLUT pass schedule information available at the associated MCC. Also, per document C/S A.001, new DOA position, if available, is distributed at least every 5 minutes prior to position confirmation and at least every 15 minutes after position confirmation. 6.13.1 LEOSAR Coverage The LEOSAR system provides two types of coverage: • Each LEOLUT provides local coverage, based on the beacon messages relayed through the SARR instruments on the LEOSAR satellites. For any given satellite pass, the coverage is limited to a swath about three thousand kilometres across, centred on the satellite ground path. As each incident alert is reported, the LUT generates an estimate of when the LUT next expects to see a satellite that will also have visibility of the location. This “Next Time of Visibility” is reported in the incident alert messages in Message Field number 29. (See also section C.1.8 of this Handbook.) • Every LEOLUT also provides global coverage, based on the data collected by the SARP instruments on the LEOSAR satellites. This data will be from all the beacons that the satellite has passed since it was last tracked by this LEOLUT. Since the coverage at any 6-32 instant depends on the past history of the satellite that will next be tracked by the LUT, it is not easy to determine when a LEOLUT is likely to generate an alert for a beacon at any given location. Since the MCC Service Area is normally in the area around the MCC and its associated LUTs, the RCCs and SPOCs in that Service Area are most likely to make inquiries about the local coverage of the LUTs. An MCC operator can review the satellite pass schedule for each of the associated LEOLUTs and estimate when the LUTs are likely to provide coverage of a specific location that may be of interest to the RCC. It may also be possible for the MCC operator to change the schedule to have the LUT track a different satellite to get better coverage of the point of interest. 6.13.2 MEOSAR Coverage The MEOSAR system provides a vast coverage area around each MEOLUT. Nominally, one MEOLUT should be able to provide DOA solution data for any beacon within two thousand kilometres of the LUT. At Full Operational Capability, the MEOSAR system has enough operational MEOLUTs and enough operational MEOSAR satellites to provide complete coverage of the surface of the Earth. So, any beacon, anywhere on the Earth, should be accurately located within about ten minutes after it has been activated. 6.13.3 GEOSAR Coverage The coverage that is available to a GEOLUT is determined by two things: • the area which the GEOSAR satellite can see and from which it can receive beacon messages (its visibility footprint), • local blockages in the area around a beacon. Subject to these two considerations, the GEOLUT should be able to detect and receive messages from any beacon at any time. The major coverage limitation for the GEOSAR system is around the poles: none of the GEOSAR satellites can see any beacon that is at a latitude that is higher than about 70°. 6.14 Beacon Testing The Cospas-Sarsat beacons may be involved in a variety of types of tests: • a beacon self-test, • a test beacon or beacon simulator, • a planned beacon test, 6-33 • a System-wide test. Each type of test requires a different notification and a different response from the MCC operator, as explained in the remaining parts of this section. 6.14.1 Beacon Self-Test Messages Every Cospas-Sarsat distress beacon is equipped with a self-test capability. This is activated by the operator of the beacon (using a specific control feature on the beacon); it will transmit one burst (one beacon message). This self-test transmission is identified as such in the encoded message: • For an FGB, the message preamble is inverted from the normal preamble, as defined in the FGB specification (document C/S T.001). • For an SGB, the message is transmitted with a distinct spreading code sequence, as defined in the SGB specification (document C/S T.018), and it includes a bit in the message that identifies this as a test transmission. In both cases, the message is immediately recognized as a test transmission. These self-test transmissions may be suppressed at the LUT, or they may be forwarded to the associated MCC. (Some MCCs analyze these self-test transmissions to help them to evaluate the accuracy of their estimates of beacon population and registration rates.) Per MCC requirements, self-test transmissions are not distributed as distress transmissions by the MCC. However, when a beacon sends several self-test messages over a relatively short period of time, and the data is received by a SARSAT satellite with a SARP-3 instrument (i.e., S11, S12 or S13), then an associated distress alert may be sent to the RCC. Awareness of this anomaly, resulting from a beacon transmission anomaly combined with a satellite processing anomaly, may allow the MCC operator (or other MCC personnel) to help the RCC or SPOC recognize the anomaly and respond, to ensure that the RCC informs the owner that the beacon is not operating correctly and that the beacon (whose battery may have been prematurely depleted) should be examined by a qualified service centre to ensure that it will operate correctly in the future. 6.14.2 Test Beacons and Beacon Simulators A test beacon has an encoded message that identifies it as such. The details of the beacon message protocols that identify test beacons are described in the appropriate 406 MHz beacon specification (document C/S T.001, C/S T.015, or C/S T.018). A test beacon will always transmit the test protocol message, and an MCC can recognize any alert message that it receives from a test beacon. A beacon simulator is a specialized instrument that transmits messages that meet the requirements of one or more of the beacon specifications. The message may indicate that it is from any 406 MHz beacon, including a distress beacon of any type or a test beacon. When one of these messages is received at a LUT, it is processed as if it were from a real 406 MHz beacon, and forwarded to the 6-34 associated MCC, as appropriate. That MCC distributes the alert according to the requirements for the type of beacon from which it appears to have been sent. 6.14.3 Notification of a Planned Beacon Test A beacon test (as distinct from a beacon self-test transmission) is the planned activation of a 406 MHz beacon for the purpose of testing the beacon or some part of the Cospas-Sarsat System. Such a beacon test is normally planned in advance, and must be authorized by the appropriate MCCs: • the MCC in whose Service Area the beacon will be activated, • the MCC whose Service Area includes the nation whose country code is encoded in the beacon message. Section 4.3 (“Procedures for the Co-Ordination of Beacon Tests”) of document C/S A.001 specifies the procedure to be followed by an MCC in approving and coordinating a beacon test. Because of the global scope of the Cospas-Sarsat System, an MCC that authorizes a beacon test is expected to notify affected (designated) other MCCs of the planned test. A template for a Beacon Test Co-ordination Message is provided in Figure 4.16 in section 4.3 (“Procedures for the Co-Ordination of Beacon Tests”) of document C/S A.001. Figure 6.13 contains a sample of a message to notify affected (designated) MCCs of a planned beacon test. 6-35 /20462 00000/5030/20 099 1721 /915/5670 /FM ITMCC TO AFFECTED (DESIGNATED) MCCS SUBJ : 406 MHZ ELT BEACON TEST A. TEST OBJECTIVE: FUNCTIONAL ELT BEACON B. TEST DESCRIPTION: NIL C. LOCATION OF TEST: VERGIATE-ITALY LAT 45 42' 47''N LONG 008 41' 57''E D. DATE/TIME AND DURATION OF TEST: 10 APRIL 2020 FROM 1300 UTC TO 1500 UTC E. BEACON 15 HEX ID CODE: 1EE87E23D6FFBFF F. SPECIAL DATA COLLECTION AND PROCESSING REQUIREMENTS: PLEASE FILTER ALERTS FROM THIS BEACON. G. POINT OF CONTACT NAME: OPERATOR ITMCC LOCATION: ITMCC OPERATIONAL ROOM TELEPHONE NO: +39 080 5344033-5341571 AFTN NO: LIJCYFYX FACSIMILE NO: +39 080 5342145 THANK YOU FOR YOUR COOPERATION BEST REGARDS ITMCC. QQQQ /LASSIT /ENDMSG Figure 6.13: Sample Message to Announce a Planned Beacon Test Activation This is a sample of a system status message to notify affected (designated) MCCs of the plans for the activation of a 406 MHz beacon in support of a system test. Requirements for the coordination of beacon tests, including limits on the number of beacons that can be tested and required notification, are provided in document C/S A.001 sections entitled “Coordination of Beacon Tests” and “Procedures for the Co-Ordination of Beacon Tests”. At a minimum, the MCC operator should be able to identify beacon test requests received from MCCs or other agencies and should follow the MCC internal procedure to ensure that the beacon test request is handled properly. 6-36 6.14.4 Processing Data from a Beacon Test The notification of the test should include an indication of what action may be expected of other MCCs during the test. There are a number of possibilities; the other MCCs may be asked to: • Ignore the beacon transmissions and suppress distribution of all alerts that may be generated as a result of this test. (See line F in the sample message in Figure 6.13.) • Forward all data received from these test transmissions to the coordinating MCC. • Perform specific processing of the data from the test transmissions and send the results to the coordinating MCC. In most cases, most (or all) of the other affected MCCs will be asked to either suppress the data or forward it to the coordinating MCC; in these cases, the request should be included in the system status message that is sent to announce the test. If specific processing is required, then it should be well-documented. (For example, the transmission and processing of test messages during the commissioning of a LUT system should be described in the LUT Commissioning Test Plan.) The document that describes the required processing should be made available to all MCCs involved, and especially to those MCCs that may be asked to perform any specialized processing. If the processing is required of only one (or a few) MCCs, then the request can be sent separately in a narrative message to the affected MCCs. In response to a beacon test request, the MCC may be required to: • Change the configuration of the MCC to support a request to distribute or suppress alert data. • Provide supporting data that is not automatically distributed for operational beacon alerts. As noted above, the MCC operator should follow the MCC internal procedure to ensure that the beacon test request is handled properly. 6.14.5 System-Wide Tests There are occasionally system-wide tests of specific features or capabilities of the Cospas-Sarsat System, such as the MEOSAR Development and Evaluation (D&E) Program. In the event that any such system-wide exercise is planned, it will be well-documented. A D&E Plan or a Test Plan document will be prepared and reviewed by the Cospas Sarsat Joint Committee, and all MCCs will be notified well in advance of the planned exercise. An exercise director or a test coordinator (and possibly a coordinating committee) will be named, and they will provide suitable notifications to all participants, both in advance of the test and during the progress of the tests. On completion, the Test Coordinator or Test Committee will generate a Test Report, to be reviewed by the Joint Committee and recommended to the Council for approval as a formal Cospas-Sarsat document. 6-37 The extent of the participation of individual MCCs in any such system-wide test will be determined by the nature of the test and by the administration of the Ground Segment Provider that operates the MCC. In general, the MCC operator is expected to follow established procedures during the test, and, as appropriate, to follow any new procedures that are being evaluated during this system- wide activity. Depending on the scale of the planned test activities, the MCC System Manager may adjust the MCC staffing schedule to ensure that the personnel on duty at any time will be prepared to handle the requirements of the test activities. Appropriate MCC personnel may be requested to participate in the analysis of the data from the tests and to assist in the preparation of the final report of the tests. - END OF SECTION 6 - Annexes to the MCC HANDBOOK C/S G.010 Issue 1 – Revision 2 ![Image 1 from page 136](/images/cospas-sarsat/G-series/G010/G010_page_136_img_1.png) Annexes to the MCC HANDBOOK HISTORY Issue Revision Date Comments Approved by CSC-64 Approved by CSC-66 [Approved by CSC-69] A-1 ANNEX A: DATA DISTRIBUTION The rules and procedures for the distribution of incident alert data and system data through the Cospas-Sarsat System are set out in document C/S A.001, “Cospas-Sarsat Data Distribution Plan” (the DDP). This section provides a summary and a brief explanation of these rules and procedures. Document C/S A.002, “Cospas-Sarsat Standard Interface Description” (the SID), defines the formats and contents of the messages that are exchanged among the MCCs in the System. The message formats that are used for the exchange of incident alert data are described in Annex B of this Handbook. A.1 Nodal Data Distribution Network As described in section 4.3 of this Handbook, the Cospas-Sarsat data distribution network is divided into a set of Data Distribution Regions (DDRs), each of which is served by a nodal MCC. This organization isolates most of the individual MCCs from the complexities of the world-wide data distribution requirements. Except for the nodal MCCs, each MCC is only required to maintain information about its own local Service Area. An incident is of direct interest to an MCC Service Area if: • the incident alert includes a location that is in the geographical area of the SRR of an RCC that is supported by the MCC (according to the Cospas-Sarsat GEOSORT); or • the incident alert is from a beacon that contains the country code of one of the nations that is included in the MCC Service Area. For each such local alert, the MCC must be able to determine which national RCC or foreign SAR Point of Contact (SPOC) is responsible for the alert and must transmit the alert to that RCC or SPOC. For any incident alert that is not of direct interest to the MCC Service Area, the MCC simply sends the alert message to its nodal MCC for further processing and distribution. The nodal MCCs are then responsible for information about the requirements for distribution of incident alert messages to the rest of the world: • If the location is within its own DDR, the nodal MCC must determine the Service Area in which it lies and send the alert to the MCC responsible for that region. • If the location is outside its own DDR, the nodal MCC must determine the DDR in which it lies and send the alert to the nodal MCC responsible for that DDR. That nodal MCC will then forward the alert to the responsible MCC within its own DDR. A-2 In each case, the non-nodal MCCs only require information about their own Service Area, while each nodal MCC must be aware of the structure of the data distribution network both inside and outside of its own DDR. However, as noted in section 4.3.2, the MCCs of the Central DDR have agreed that all MCCs in that DDR will exchange alerts directly, without going through the nodal FMCC. For this reason, every MCC in the CDDR must have the complete GEOSORT for the CDDR. A.1.1 Special Rules The general rules that are set out in the Cospas-Sarsat Data Distribution Plan are all subject to variation by mutual agreement among MCCs, or between an MCC and one or more of its SPOCs. The major example of such an agreement is in the Central Data Distribution Region (CDDR), where each MCC has accepted the responsibility to send an incident alert for another CDDR MCC directly to the destination MCC without going through the nodal French MCC. A.1.2 Cospas-Sarsat GEOSORT The Cospas-Sarsat GEOSORT is a database that contains the list of boundary points of the Service Area of every commissioned MCC. It is maintained by the Cospas-Sarsat Secretariat, and it is reviewed and updated as necessary by the Cospas-Sarsat Joint Committee; it is made available on request to any of the MCCs in the Cospas-Sarsat Ground Segment. Each MCC supplements the Cospas-Sarsat GEOSORT with its own database, which contains the list of boundary points of the SRRs of every RCC or SPOC that is served by that MCC. Each MCC uses this data to decide which region contains any point (usually a beacon location) of interest to the MCC and to determine the appropriate destination for that incident alert message. The nodal MCCs use the complete GEOSORT to determine the MCC Service Area that contains a beacon position. Once the MCC has determined the MCC Service Area to which a beacon location belongs, it can then proceed to send the incident alert message for that beacon to the appropriate MCC, to be forwarded to the SAR service that will deal with the distress incident. A.1.2.1 Data Distribution Regions As noted in section 4.3.2, above, a Data Distribution Region (DDR) is the region that is managed by a nodal MCC; each DDR consists of the collected Service Areas of all the MCCs that are supported by that nodal MCC. When a nodal MCC is considered for commissioning into the Cospas-Sarsat Ground Segment, the set of MCC Service Areas that will be served by that nodal MCC are proposed and reviewed by the Cospas-Sarsat Joint Committee; the final set of agreed MCC Service Areas is then approved by the Cospas-Sarsat Council. The existing Cospas-Sarsat data distribution system is comprised of six different DDRs, as listed in Table 4-2 and illustrated in Figure 4.4. A-3 A.1.3 MCC Service Areas As explained in section 4.3.1, an MCC Service Area is the region that is serviced by the MCC. When a new MCC is commissioned into the Cospas-Sarsat Ground Segment, the Service Area that will be supported by that MCC is agreed and the set of boundary points for the region are included in the Cospas-Sarsat GEOSORT database. A.1.4 Message Formatting The messages that are used to transmit information from one MCC to another, or to a SPOC, are formatted according to the requirements of the document C/S A.002 (Standard Interface Specification), as described in Annex B of this Handbook. As explained in that Annex, each message is built from a series of data message fields (MFs), each of which contains a specific item of information about the solution. The tables in this Annex A identify the data that is contained in the various messages; they include (in the “References” column) references to the sections or the tables in Annex B that provide more comprehensive explanations of the message fields that are used to hold that data. Every message includes the message control fields described in section A.10.1 of this Handbook. Each individual message also includes the data message fields, as identified in the tables in the following sections of this Annex A and in Annex B that describe the information appropriate to the specific message that is being prepared. A.1.5 Alert Message Validation As each incident alert message is received by an MCC, the contents of that message are checked and validated. Several types of message validation are performed: • Each character in the message is checked to ensure that its contents are consistent with the specifications in the SID (document C/S A.002). If the message fails this initial validation, then it cannot be processed by the MCC. The operator is notified and should contact the originator of the message: • If a valid incident alert was sent, then the message should be re-transmitted and processed when it is correctly received. • If the message was not valid as sent, then the originator of the message should make the necessary corrections and send the valid message for processing. A message that passes the initial validation is then checked to verify the data in the beacon message that is contained in the alert: • The Bose–Chaudhuri–Hocquenghem (BCH) error correcting code (ECC) is checked to ensure that the beacon message contained in the alert has not been corrupted in transmission. See section A.6.7 in Annex A of this Handbook for a more complete explanation of the bit error processing. A-4 • Selected supplementary data fields in the beacon message are checked (as described in section 4.2 of C/S A.001) to ensure that their contents are valid. These fields, and the valid contents, are identified in the DDP. If the beacon message data passes all the validation checks, then the message is accepted as valid and is processed. If the beacon message fails any validation check, then the alert will still be processed, but none of the data that is contained in the beacon message will be used in the processing. Essentially, an alert containing a beacon message that fails validation will be processed according to the independent location data that may be contained in the alert. However, any other data from the beacon message, such as the country code or the encoded location data, will not be accepted as valid, and will not be used to determine the subsequent processing of that alert. A.2 Alert Data Distribution The rules for the distribution of incident alert data are set out in the DDP (document C/S A.001) and are detailed in a series of tables (called “Processing Matrices”) in section 4 (“Operational Procedures for Cospas-Sarsat MCCs”) of that document. There is a different table for each set of conditions under which the message must be distributed. Section A.3 describes the structure and contents of these processing matrices. A.3 DDP Processing Matrices The processing matrices are a series of tables in the DDP that define the processing that an MCC must do in the various circumstances that may arise. These matrices each contain a series of subscripted variables that define the data: • The Input (In) identifies the type of input data that is to be processed by the MCC. The Input word is specific to each individual input and is independent of the origin of the data (e.g. another MCC or the LUTs associated with the receiving MCC). • The current Status word (Swp) indicates the status of the processing of the beacon before the input data is processed. The Status word summarises all previous inputs and actions in respect of a particular beacon ID. • The action word (Awq) indicates the action that the MCC should take as a result of the processing of In in the situation indicated by Swp. The Actions to be carried out as a result of the process depend on the Input / Status combination, but also on the results of comparisons (matching tests) between ‘old’ and ‘new’ position data received by the MCC, as shown in the matrix that applies to this input message. • The new status word (Swr) indicates the new status the MCC should set as a result of the processing of In in the situation indicated by Swp. This processing is illustrated in Figure 4-10 (“Alert Data Processing Concept”) of the DDP, which is reproduced in this Handbook as Figure A.1. A-5 The Action word that is selected as a result of the processing of an input message defines: • The message format to be sent, and • (Before position confirmation) the new status to be associated with that beacon ID after completion of the selected Action. Figure A.1: Alert Data Processing Concept This illustration summarizes the functional relationships among the position information content of the input message, the status word, and the action generated by the MCC processing. Each of the subscripts denotes the nature of the data to which it relates, as listed in Error! R eference source not found.1. The subscript for the input will depend on the nature of the input data that is being processed. In the table, an independent position may be either a LEOSAR Doppler position or a MEOSAR DOA position (or some combination of Doppler and DOA positions). Table A-1: Subscripts used in Processing Matrices This table defines the meaning of the subscripts that are used in the processing matrices in the DDP (document C/S A.001). Subscript Description No message received or sent Unlocated alert Independent positions only Encoded position only Independent and Encoded positions, all unmatched Independent position only, position confirmed Independent position (confirmed) and Encoded position unmatched Resolved positions (Independent & Encoded matched) ![Image 1 from page 142](/images/cospas-sarsat/G-series/G010/G010_page_142_img_1.png) A-6 As indicated in Figure A.1, the subscript for the new status word, after the processing of this input message is complete, will have a subscript (r) that is the greater of: • the subscript (p) of the original status word, • the subscript (q) of the action word that results from the processing of this input. The new status word subscript will then be retained to be used to direct the processing of the next alert received for this beacon. The processing matrix is then a table that shows the Input word values across the top (from 1 to 7; a value of 0, meaning no input, is obviously not appropriate) to identify the columns, with one row for each Status word value (although the entries for Sw5, Sw6, and Sw7 are all treated in the same row). Each entry in the table then defines the results to be generated for the relevant combination of input (In) and current status (Swp). Each entry consists of a block of values that define the results of the processing of the indicated combination of input and status, as shown in Table , which is an extract from Table 4-11 (“Processing Matrix, Message Formats and Distribution of New 406 MHz MEOSAR Alerts”) of the DDP (document C/S A.001). Table A-2 - Extract from MEOSAR Processing Matrix This table is an extract from the processing matrix for a new MEOSAR alert; Table 4-11 (Processing Matrix, Message Formats and Distribution of New 406 MHz MEOSAR Alerts) in the DDP (document C/S A.001). I4 (DOA / E unmatched) Aw SIT Dest Sw2 Aw7 n47 RIP Aw6 n47 RIP Aw4 n46 OEP This entry shows the processing of a new MEOSAR DOA solution with an encoded position that does not match the DOA position in the message (I4). The current status when this alert is received is Sw2, meaning that the MCC has previously received one or more alerts that only contained DOA (or Doppler) solutions. The results of the MCC processing are indicated in the three lines of the entry: Line 1. If the position of the incident is confirmed by the MCC processing, the action is Aw7 (send an alert message). The MCC should send the alert message in SIT n47 format (SIT 147 or SIT 347, depending on whether the beacon that sent this alert is an FGB or an SGB; see below). The final code is RIP, meaning that the MCC should send the alert to the destinations defined by: A-7 • (R) the SRR in which the confirmed position is located, • (I) SRR in which the incorrect previous position is located, • (P) all previous recipients of alerts for this incident. Line 2. If the position of the incident is confirmed by the MCC processing but the confirmed position does not match the new encoded position, the action is Aw6 (send an alert message). The MCC should send the alert message in SIT n47 format (SIT 147 or SIT 347, depending on whether the beacon that sent this alert is an FGB or an SGB; see below). The final code is RIP, meaning that the MCC should send the alert to the destinations defined by: • (R) the SRR in which the confirmed position is located, • (I) SRR in which the incorrect previous position is located, • (P) all previous recipients of alerts for this incident. Line 3. If the position of the incident is not confirmed by the MCC processing and the new DOA position does not match the new encoded positions, the new action is Aw4 (send an alert message). The MCC should send the alert message in SIT n46 format (SIT 146 or SIT 346, depending on whether the beacon that sent this alert is an FGB or an SGB; see below). The final code is OEP, meaning that the MCC should send the alert to the destinations defined by: • (O) the SRR in which the new DOA position is located, • (E) the SRR in which the new encoded position is located, • (P) all previous recipients of alerts for this incident. In the “SIT” column, the SIT message format number is listed as “n--”, where n may be: • For a first-generation beacon, n=1, • For a second-generation beacon, n=3. So, in the second row of the example, the MCC would send a SIT 147 message for an FGB and a SIT 347 message for an SGB. In the “Dest” (destination) column, the destination code may be any of the letters listed in Table . Table A-3: Processing Matrix Destination Codes This table contains some of the notes from the processing matrix for a new LEOSAR alert; Table 4-10 (Processing Matrix, Message Formats and Distribution of New 406 MHz LEOSAR Alerts) in the DDP (document C/S A.001). A-8 Code Meaning A Destinations defined by the A-position of a LEOSAR Doppler solution B Destinations defined by the B-position of a LEOSAR Doppler solution E Destinations defined by the encoded position in the beacon message O Destinations defined by the position of a MEOSAR DOA solution R Destinations defined by the confirmed position of the incident I Destinations defined by all of the incorrect positions that have been processed previously by this MCC C Destinations defined by the country code that is encoded in the beacon message RD Destinations defined by the post-confirmation positions (that is, all positions found after the initial confirmation of this incident) P All previous recipients of alerts about this beacon incident A.4 Alert Types A.4.1 Unlocated Alerts If the alert data does not include any estimate of the location of the beacon, then the incident alert message will have to be distributed to the country that is identified in the beacon message. (Note, however, that the country code will only be used if the beacon message is valid; otherwise, the content of the message, and specifically the country code, is not reliable, and no incident alert message will be sent for this incident.) If the country identified in the beacon message is included in the Service Area of this MCC, then the incident alert message will be transmitted to the associated RCC or SPOC. Otherwise, the incident alert data will be sent to the nodal MCC that is associated with this MCC, and the nodal MCC will determine the appropriate onward distribution. Once the destination has been established, the message format will be decided (as described in the SID, C/S A.002), and the message text will be generated. The incident alert message will then be transmitted, as specified in document C/S A.001 (Data Distribution Plan) and described in the appropriate section of this Annex. A.4.2 Alerts with Beacon Position Estimates An incident alert message will usually contain an estimate of the beacon location, which may be any one or more of: • An encoded location determined by the beacon and included in a valid beacon message, • An independent location determined by the Doppler processing in a LEOLUT, • An independent location determined by the Difference of Arrival (DOA) processing in a MEOLUT, A-9 • A confirmed location estimate, based on two or more location estimates of one or more of the location types listed above. Whenever a beacon position estimate is available, the MCC evaluates the location against the Cospas-Sarsat GEOSORT to determine the appropriate destination for that incident alert. It also considers any information that has previously been received about the same beacon, and, depending on the evaluation of the processing matrix, determines whether or not a new alert message should be sent out. Note that each destination MCC may request the continued distribution or the suppression of alerts for any specified beacon, and thereby over-ride the automatic routing (or suppression) of future alert messages from that beacon. A.4.2.1 Position Data The position data for every location that is included in every incident alert message (whether it is a LEOSAR Doppler position, a MEOSAR DOA position, or an encoded position) consists of: • Latitude The latitude is stored internally in the system, and displayed in MF \#25, as a real number of degrees North or South of the equator. A positive number indicates North, and a negative number indicates South. • Longitude The longitude is stored internally in the system, and displayed in MF \#26, as a real number of degrees East or West of the prime meridian. A positive number indicates East, and a negative number indicates West. The position data that is included in a MEOSAR DOA incident alert message also includes: • Altitude The altitude is stored internally in the system, and displayed in MF \#82, as a real number of kilometres above the surface of the reference ellipsoid (the nominal sea level). The value displayed in MF \#82 is always positive; a value below sea level will show as zero. The position data is always computed and displayed in the World Geodetic System (WGS84) reference system. This reference coordinate system is the standard used by the Cospas-Sarsat System; it is also used by the Global Positioning System (GPS) and is within a few centimetres of the reference systems used by the other Global Navigation Satellite Systems (GNSS). A.4.3 Confirmed Beacon Alerts Before an alert has been confirmed, the location data is sent to the RCC. Although this data may not have enough information for the RCC to pursue the rescue, the RCC may have information from other sources that will help to resolve the solution ambiguity, as described in section C.1.2.1 of this Handbook. Alternately, the RCC may have to wait until the MCC can resolve the ambiguity (as described above). Once the solution ambiguity is resolved, the new alert can be distributed as a confirmed alert, with sufficient information for the RCC to address the alert. A-10 If a beacon is detected with a location estimate (either a encoded location in the beacon message or an independent location estimate from the LEOSAR Doppler processing or the MEOSAR DOA processing), then the incident alert message is distributed; however, the message format is specifically labelled to identify it as an unconfirmed alert. If a beacon is detected through at least two different independent channels, then the messages will be compared to determine if the beacon activation and detection can be confirmed. Two data channels are considered to be independent if they contain information that can not have been duplicated, as explained in section 4.3.4.4 of this Handbook. Once the alert has been confirmed, a separate message will be distributed to identify that this is a confirmed alert report. A.4.3.1 Matching and Merging of Beacons As each incident alert message is received at an MCC, the alert data is compared to the alert data that is already held in the MCC (based on previously received alert messages). The first step in matching the new alert to a previous alert is to compare the beacon identifiers: • If the beacon message is valid, then the corrected beacon identifiers (without the BCH code) are matched. • If the beacon message is not valid, then the entire beacon messages (including all of the BCH code bits) are matched. In each case, if a match is found, then the new alert data is compared to the previous data, and the new alert is processed accordingly. A.4.3.2 Beacon Confirmation If the beacon identifications from two independent detections match, as described above, then the beacon activation may be considered to have been confirmed. That is, the MCC will accept that the beacon has been activated, and that it should continue to process reports from that beacon accordingly. A.4.3.3 Position Confirmation If the solutions that contribute to a confirmed alert include a location estimate, then the position of the confirmed solution can also be confirmed. A position estimate is confirmed if a second location estimate, from an independent source, as described in section 4.3.4.4 of this Handbook, matches the initial estimate to within the match criteria listed in section 4.2.2 (“Position Matching”) of the DDP. A.4.3.4 Distribution of Confirmed Solutions The specifications for the processing of alert confirmation and ambiguity resolution are contained in document C/S A.001, in the remaining columns of the processing matrix in Table 4-10 A-11 (“Processing Matrix, Message Formats and Distribution of New 406 MHz LEOSAR/GEOSAR Alerts”) and Table 4-11 (“Processing Matrix, Message Formats and Distribution of New 406 MHz MEOSAR Alerts”), and in the accompanying text in sections 4.2.5.3.1 (“Processing Before Position Confirmation”) and 4.2.5.3.2 (“Processing After Position Confirmation”). These specifications are discussed in more detail in section A.6.5 of this Handbook. A.4.3.5 Conflict Solutions Once a solution has been confirmed, it is expected that subsequent reports of the same beacon will continue to point at the same position. However, there are situations where the new solution does not match the confirmed solution: • If the beacon is moving, the new solution will reflect the new position of the beacon. For a moving beacon, the position will normally continue to move as time passes. • If the new solution is in error, then it will conflict; however, subsequent solutions should then match with the original confirmed solution. • If the solutions that generated the original confirmed solution were in error, then the new solution will eventually be confirmed by a subsequent solution, and the old confirmed solution will be discarded. In any case, the conflicting solution will be reported in a special format, so that the receiving MCC (or RCC) will be aware of the conflict. A.4.4 Alert Message Contents Each incident alert message contains a series of message data fields that carry specific items of information about that alert. Every incident alert message includes the message control fields that are listed in Table in section B.4.1 of this Handbook. The following paragraphs and the tables to which they refer (from section B.4 of this Handbook) identify the message data fields that are used specifically for incident alert messages. In each of these tables, the entry under MF \#is the Message Field number, as defined in document C/S A.002, “Cospas-Sarsat Standard Interface Description” (the SID), that is used to identify that data item. Note that these tables do not include information about the text or data that may be included in the SIT 185 or SIT 985 messages. Many of the solutions generated by the Cospas-Sarsat System produce beacon positions, including estimates of the longitude and latitude of the beacon. Table in Annex B of this Handbook identifies the data items that are contained in the Cospas-Sarsat incident alert data messages. Of course, each incident is the result of the activation of a beacon, which will be detected and reported through more than one of the different sub-systems operated by Cospas-Sarsat; in fact, any active beacon will most likely be detected and processed by all of the Cospas-Sarsat sub- systems. The “System” column of Table of this Handbook identifies the data items that apply to each of the sub-systems. This allocation may only apply to the first detection (depending on the sub-system by which the beacon was detected and processed first). Subsequent reports will most A-12 likely include some combination of the features of the individual sub-systems that have contributed to the generation of the data used in the alert. Each solution that is generated by the Doppler processing that is performed by the LEOSAR system consists of two possible positions (usually denoted as the A- and B- locations), symmetrically placed across the satellite orbit plane. Each of these positions is identified by a set of data items; two complete sets are used to describe the solution. The data items that are used in the incident alert messages that are based on beacons detected and processed through the LEOSAR satellites and the associated LEOLUTs are labelled as “All” or as “LEOLUT” in Table of this Handbook. The MEOSAR DOA processing normally generates a single position estimate with each solution. The data items that are used in the incident alert messages that are based on beacons detected and processed through the MEOSAR satellites and the associated MEOLUTs are labelled as “All” or as “MEOLUT” in Table of this Handbook. The GEOSAR system is not able to generate an independent location estimate. The data items that are used in the incident alert messages that are based on beacons detected and processed through the GEOSAR satellites and the associated GEOLUTs are labelled as “All” or as “GEOLUT” in Table of this Handbook. A.4.5 Alert Message Routing Once the destination of the message has been determined, then the MCC must decide on the format to be used for the message. The available options are: • If the destination is another MCC, then the appropriate SIT message format should be used, depending on the nature of the alert data. • If the destination is a foreign SPOC, then the SIT185 message format should be used. The details of the contents to be placed in the message will depend on the nature of the alert data. • If the destination is a national RCC, then the MCC will use the message format that is defined by the national Administration for communications with the associated RCC. This will usually be the SIT 185 message format (or a variant thereof), but it may be a completely independent message format. The text of the formatted message, as appropriate, is generated. The incident alert message will then be transmitted, as specified in document C/S A.001 (Data Distribution Plan) and described in the appropriate section of this Annex. A-13 A.4.6 Continued Transmission The normal procedure for the distribution of alerts is to send every new alert to the destination authority, unless the new alert is redundant with a previously transmitted alert. However, an RCC may want to consider not receiving subsequent alerts for the same beacon, for a variety of reasons: • The RCC may have investigated and determined that this beacon activation is not related to any real distress incident. • The RCC may have already dealt with the distress incident signalled by the beacon activation. • The RCC may have been in contact with the person(s) in distress and may not require further information about the incident. • The RCC (or the MCC) may be aware that a beacon test is planned (or in progress), and that the RCC does not need to be notified of the test data. In any of these (or similar) situations, the MCC must be able to suppress the transmission of any future alert for a given beacon, or from any beacon in a specified area. Similarly, after the transmission of alert data has been suppressed, the MCC operator may wish to resume transmission of the suppressed alerts. For either of these situations, the MCC operator may specify either the identifier of the beacon or the region where the beacon is located. (The region may be described as either as a circle around a specified point, or as a range of latitude and longitude values). As each beacon alert is received and processed at the MCC, the MCC must recognize these situations and distribute the alert (or not distribute the alert) accordingly. The specifications for the processing of continued transmission of alerts are contained in sections 3.2.5 (“Continued Transmission after Position Confirmation”) and 3.2.7 (“Requesting Transmission of Alerts”) of document C/S A.001. These specifications are discussed in more detail in section A.5 of this Handbook. A.4.7 Special Processing As indicated in section 4.3.4.5 of this Handbook, the normal sequence of incident alert message processing may have to be changed to meet the special requirements of certain circumstances. These circumstances may arise because of the nature of the beacon or the contents of the incident alert message. Beacons that require special processing include: • Ship Security Alerting System (SSAS) beacons, • Return Link Service (RLS) beacons, • Distress Tracking (ELT(DT)) beacons, • System Beacons. A-14 Other situations that may require special processing include: • Notification of the country where the beacon is registered (as indicated by the country code in the beacon message), • Alert cancellation messages. The special processing for each of these situations is described in the following paragraphs. A.4.7.1 Ship Security Alert An SSAS beacon is a beacon that has been designed to report a threat to the ship on which it is carried. These beacons are designed for manual operation, and they have a special identifier code that identifies them as SSAS beacons. These beacons are intended for the use of ships that may be under attack, from pirates, hijackers, or other enemies. While these incidents are true distress incidents, they are not the sort of incidents that the Search and Rescue (SAR) forces of an RCC are prepared to address. These incident alert messages are not sent to the SAR forces. Instead, they are sent directly to a competent authority, which has been designated by the administration of the country in which the SSAS beacon is registered (and whose country code is encoded in the beacon message), for action. This enables the authorities in that nation to address the issue. The specifications for the processing of SSAS alerts are contained in section 4.2.8 (“Distribution of 406 MHz Ship Security Alerts”) in document C/S A.001. Document C/S A.002 contains the specifications for the message formats that are used to transmit the alert data for an SSAS beacon; these formats are discussed in more detail in section B.5.9 of this Handbook. A.4.7.2 Return Link Service Alert The Return Link Service (RLS) is a special service that is offered by some MEOSAR Space Segment Providers, who are also the operators of Global Navigation Satellite Systems (GNSS). It offers the capability to send messages to beacons that support the RLS capability via the navigation downlink signals from their GNSS satellites. Cospas-Sarsat supports the use of this service for the transmission of Type-1 acknowledgement messages to active distress beacons. The Type-1 acknowledgement message is intended to acknowledge that the distress alert has been detected by the Cospas-Sarsat System; it is not intended to provide any assurance that the alert has been received by an RCC or that any action has been taken on that alert message. The illustration in Figure A.2 shows the flow of data for the generation of the Type-1 acknowledgement when an alert is received from an RLS beacon. When the responsible MCC receives an alert from an RLS beacon, it generates a Return Link Message (RLM) request that is sent to the MCC associated with the Return Link Service Provider (RLSP); this information is used by the RLSP to trigger the generation of the Return Link Message (RLM) to the beacon. A-15 Figure A.2: Return Link Service This illustration shows the flow of data for an alert from an RLS-capable beacon. At the present time, the following GNSS support an RLS capability: • SAR/Galileo (Interim Operational Capability), • SAR/Glonass (planned), • SAR/Beidou (planned). The operator of each of these GNSS services is required to designate an MCC that should be notified when an incident alert is received from an RLS beacon; this designated MCC is to be notified of the alert by the MCC that sends the incident alert message to the responsible RCC or SPOC. The designated RLS support MCC is then responsible to interface with the GNSS operator to notify it of the beacon activation, with an estimated beacon location. Based on this information, the GNSS operator can then send the response message to the beacon. A distress beacon that supports the RLS is encoded with a digital message in a special format, as defined in the appropriate beacon specification document (document C/S T.001 or C/S T.018). When a message is received at an MCC from an RLS-capable beacon, it is processed in the same way as any other distress alert; the only exception is that, in addition to the normal distress alert message, the MCC also forwards that incident alert message (in a special format defined in C/S A.002) to the MCC that supports the Return Link Service Provider (RLSP). The RLSP associated with each operational RLS is identified in Table 4-16 (“Associated MCCs for Return Link Service Providers”) of C/S A.001. ![Image 1 from page 152](/images/cospas-sarsat/G-series/G010/G010_page_152_img_1.png) A-16 When the MCC that supports the RLSP receives an RLS message, it notifies the RLSP that the alert has been received and processed by the Cospas-Sarsat System. The RLSP then takes the necessary action to generate and transmit the Type-1 acknowledgement message to the beacon. An RLS beacon is equipped with a means to notify the user when the acknowledgement message is received at the beacon. It should be noted that the Type-1 acknowledgement is only intended to indicate that the alert has been received by the Cospas-Sarsat System and forwarded to the appropriate RCC. It does not confirm that the RCC has received the alert message, nor does it otherwise indicate that any action has been (or is being) taken towards a rescue. However, it does provide some reassurance that the occurrence of the distress incident has been reported, and some hope that help will come. (A Type- 2 acknowledgement, which has been proposed by the European Commission for use with their Galileo GNSS, but which is not currently implemented in the Cospas-Sarsat System, would be generated on the initiative of the RCC, and would indicate that the RCC is taking action towards the rescue of the persons in distress.) The final MCC in the alerting chain (that is, the MCC that is responsible for sending the incident alert message to the RCC or SPOC) is the one that is required to notify the MCC that has been designated by the GNSS operator. While this may result in more than one alert going to the designated MCC (especially if the location of the distress incident moves from one MCC Service Area to another), it is intended to minimize the duplication of these messages. Note that the RLS operator notification message is sent in addition to the normal distress alerting messages. Those incident alert messages will continue to be formatted and transmitted to the appropriate destination, independently of the RLS notification message. Once the RLSP has been notified of the activation and detection of the RLS beacon, the Cospas- Sarsat MCC does not perform any other special processing of future messages from that activation of the beacon. The specifications for the processing of RLS alerts are contained in section 4.2.10 (“Return Link Service (RLS) Procedures”) of document C/S A.001. Document C/S A.002 contains the specifications for the message formats that are used to transmit the alert data for an RLS beacon; these formats are discussed in more detail in section B.5.10 of this Handbook. A.4.7.3 Distress Tracking ELT Alert As explained in section 2.2.1.1 of this Handbook, ICAO is developing a Global Aeronautical Distress and Safety System (GADSS). The requirements for the GADSS are specified in various amendments to the Annexes to the Chicago Convention, and in other documents such as ICAO document 10054, “Manual on Location of Aircraft in Distress and Flight Recorder Data Recovery”. Among other things, the GADSS requires that all commercial aircraft must carry a device that will provide information, at one-minute intervals, at any time the aircraft is in a potential distress situation; that is, a situation which if continued is likely to lead to an accident. The details of the A-17 conditions that may indicate the potential distress situation and trigger the beacon are outside the scope of Cospas-Sarsat; they may include such things as: • Ground proximity indication, • Loss of engine power, • Unusual aircraft attitude. The actual indications are specified in the document ED-237, issued by the European Organisation for Civil Aviation Equipment (EUROCAE). Regardless of these details, the intent is that the beacon should provide sufficient information that the aircraft operator (in ICAO terminology, this is the airline that operates the airplane) should be able to determine the position of the aircraft after a crash with an accuracy of six nautical miles (approximately eleven kilometres). In support of this ICAO initiative, Cospas-Sarsat is developing the specifications for a distress tracking ELT: an ELT(DT). An ELT(DT) beacon will be encoded with a digital message in a special format, as defined in the appropriate beacon specification document (document C/S T.001 or C/S T.018). The illustration in Figure A.3 shows the support that is provided by the Cospas-Sarsat data distribution system when an alert is received from an ELT(DT) beacon. Figure A.3: Distress Tracking Alert Support This illustration shows the support that Cospas-Sarsat provides for an alert from a Distress Tracking beacon. ![Image 1 from page 154](/images/cospas-sarsat/G-series/G010/G010_page_154_img_1.png) A-18 When an MCC receives an alert message that is from an ELT(DT) beacon, it will be processed in the same way as any other distress alert, with some exceptions: • The incident alert data will be written to a separate database, the Location of Aircraft in Distress Repository (LADR), operated by (or for) ICAO, so that the data is available to any of the interested parties: - The airline that operates the aircraft that may be in distress, - the Air Traffic Service Unit(s) (ATSU), such as Air Traffic Control centres, that may be in contact with the aircraft, - The Rescue Coordination Centre that may have to respond to the accident if (or when) it happens, - Other responsible parties that may be authorized by the administration of the country where the beacon has been located, - Other responsible parties that may be authorized by the administration of the country where the beacon has been registered. • The rules for determining when a detection is redundant will be relaxed, to ensure that every ELT(DT) alert is forwarded through the data distribution system to the LADR and to the responsible RCC. • The alert will be sent to the RCC or SPOC in a special variation of the SIT 185 format, so that it will be recognized as an alert of a potential distress (as distinct from an actual airplane crash report). Beyond these amendments, an incident alert from an ELT(DT) is processed in the same way as any other distress alert and is sent to the RCC using the normal data distribution procedures. ICAO has not yet (in mid-2023) completed implementation of the LADR. However, plans call for nodal MCCs to provide the data on ELT(DT) activations to the LADR in the ICAO-specified format. The specifications for the processing of ELT(DT) alerts are contained in document C/S A.001, in Figure 3-2 (“406 MHz Alert Data Distribution Procedures - ELT(DT)s”), in section 3.2.3.2.2 (“Filtering of Redundant Data for ELT(DT)s”), in section 3.7.10 (“Operational Distribution of Alert Data for SGBs and FGB ELT(DT)s”), and in section 3.12 (“Autonomous Distress Tracking Data Repository for ELT(DT) Alert Data”). Document C/S A.002 contains the specifications for the message formats that are used to transmit the alert data for an ELT(DT) beacon; these formats are discussed in more detail in section B.5.10 of this Handbook. A.4.7.4 System Beacons A System Beacon is any 406 MHz beacon that is designed for use other than as an operational distress beacon. These beacons are encoded with unique identifiers, so that they will be recognized as orbitography beacons, MEOSAR calibration beacons, reference beacons, test beacons, or A-19 beacon simulators. These beacons are all intended to be used to support the operation of the Cospas-Sarsat System. Among other uses: • Calibration beacons support the operation of some part of the Cospas-Sarsat System: - Orbitography and reference beacons are used for the computation of accurate orbit ephemeris data for operational satellites. - The T-Cal beacons and reference beacons are used for the calibration of the data processing for a Cospas-Sarsat LUT: ▪ Sarsat LEOSAR SARP frequency reference, ▪ Sarsat LEOSAR SARP time reference, ▪ SARR frequency reference. - MEOSAR calibration beacons and reference beacons are used for the calibration of the MEOSAR system processing: ▪ At least one reference beacon near the edge of each MEOLUT Designated Coverage Area (DCA) or at least one thousand kilometres from the MEOLUT, ▪ Technical parameters as defined in C/S A.003 (section 2.3.2.1, “Designated QMS Reference Beacons”), ▪ Coordinated regionally to maximize the usability and to minimize the impact on System operations. • Beacon simulators and test beacons support the performance of tests of some part of the Cospas-Sarsat System: - Beacon tests, including beacon type-approval tests, - LUT tests, including LUT commissioning tests, - MCC tests, including MCC commissioning tests, - Tests of the capabilities of an RCC or another rescue service. • Reference beacons support the Quality Management System (QMS) assessment of the capabilities of the Cospas-Sarsat System: - The reference beacons at McMurdo and Longyearbyen are used to confirm the continuous monitoring capabilities of the LEOSAR system, - The reference beacons at Toulouse, Edmonton, and Kerguelen are used to confirm the continuous monitoring capabilities of the GEOSAR system, - The designated reference beacons (as defined in C/S T.022 and C/S A.003) transmit special sequences of messages to mimic beacon events. • System beacons support the demonstration of the capabilities of the Cospas-Sarsat System - System Demonstration and Evaluation Programs, - More comprehensive System tests or System exercises. A-20 In the beacon specification documents C/S T.001 and C/S T.018, special beacon identifiers are reserved for these orbitography and test beacons. In order to avoid conflicts in the assessment of the System, beacons that are used for calibration of one or more System elements may not also be used as a designated QMS reference beacon. A list of reference beacons that are available for System calibration and for QMS evaluation is available on the Cospas-Sarsat website. When an alert is received from a test or reference beacon, the processing will be different from the normal beacon message processing: • If the beacon has been designated for use as a QMS reference beacon, then the solution data associated with this detection is sent directly from the LUT to the associated MCC. It may be kept locally in the MCC or may be forwarded to the nodal MCC, for use in evaluating the performance of the System. • If the beacon has been designated for use as an orbitography beacon, the data will be used internally in the LUT to update the orbital elements of the satellite that relayed the beacon signal to the Ground Segment. In this case, the MCC will not forward the beacon data to any other MCC, SPOC, or RCC. • If the beacon has been designated for use as a calibration beacon, the data will be used internally in the LUT to update the appropriate calibration data for the satellite that relayed the beacon signal to the Ground Segment. In this case, the MCC will not forward the beacon data to any other MCC, SPOC, or RCC. • If the beacon has been designated for use during a system test, then the processing will depend on the requirements of the specific test that is planned. In such a case, the beacon identifier(s) will be sent to all MCCs in advance of the test, and instructions for the distribution of the data collected from these beacons will normally be included in the Test Plan. The data may be: - Distributed as normal incident alert data, - Sent to a specific designated MCC for evaluation, - Analyzed (according to the requirements of the Test Plan) at each MCC, - Stored for future analysis, but not distributed through the Cospas-Sarsat System. Depending on the nature of the test, some or all MCCs may be expected to participate in the test, and to collect and process the data from the reference beacons. The flow of data from the designated MEOSAR QMS reference beacons to the nodal MCC, where the data is processed and the results are published, is illustrated in Figure A.4. For more detailed information about the MEOSAR reference beacons: • The detailed technical requirements for each MEOSAR reference beacon are specified in C/S T.022, “Cospas-Sarsat MEOSAR Reference Beacon Network Design Guidelines”. A-21 • A list of the designated reference beacons that are used by each MEOLUT is provided in the MEOLUT Commissioning Report for that MEOLUT. • A summary of the technical parameters of each operational MEOSAR reference beacon is available on the Cospas-Sarsat website. The specifications for the processing of reference beacon alerts are contained in the text in section 2.3.2.1 (“Designated QMS Reference Beacons”) of document C/S A.003, “Cospas-Sarsat Monitoring and Reporting”. Document C/S A.002 contains the specifications for the message formats that are used to transmit the alert data for any beacon; these alerts for test and reference beacons are normally transmitted in the same message format as any normal incident alert message. These message formats are discussed in more detail in Annex B of this Handbook.” Figure A.4: Flow of Cospas-Sarsat QMS Data This illustration shows the flow of data from the designated Cospas-Sarsat MEOSAR QMS reference beacons through the Ground Segment to the nodal MCCs for evaluation. A.4.7.5 Notification of Country of Registration Alert An incident alert message will normally be sent to the MCC whose Service Area includes the location where the beacon has been located. However, if the beacon message contained in the alert data includes a valid country code, then the incident alert message will also be distributed to the ![Image 1 from page 158](/images/cospas-sarsat/G-series/G010/G010_page_158_img_1.png) A-22 country that is identified in the beacon message, as a Notification of Country of Registration (NOCR) message. This provides the authorities in that country with the knowledge of any distress situation that may involve their own nationals and enables them to offer the local authorities any assistance that may be appropriate under the circumstances. Although the NOCR message is not officially a request for beacon registration data, the receiving MCC may wish to respond by sending the available registration data to the originating MCC or to the RCC that will be responsible for the SAR response to the reported incident. If the country is included in the Service Area of this MCC (as identified in a configuration file in the MCC), then the incident alert message will be transmitted to the appropriate RCC or SPOC. Otherwise, the incident alert data will be sent to the associated nodal MCC, which will determine the appropriate onward distribution. The NOCR message is in addition to any other incident alert message that may be generated by the system. However, if a distress alert message has already been sent to the country of registration, then a separate NOCR message would be redundant, and will not be sent. Once the destination has been established, the message format will be decided (as described above, but using the appropriate NOCR message format), and the message text will be generated. The incident alert message will then be transmitted, as described in section A.5 of this Handbook. The specifications for the processing of NOCR alerts are contained in section 4.2.7 (“NOCR Procedures”) of document C/S A.001. Document C/S A.002 contains the specifications for the message formats that are used to transmit the alert data for notification of the country of registration; these formats are discussed in more detail in section B.5.8 of this Handbook. A.4.7.6 Cancellation Message Some distress beacons include a capability for the user of the beacon to cancel the alert; this is done by the transmission of a special cancellation message from the beacon. A cancellation message indicates that there is no distress incident in progress. This may be because the beacon was triggered by accident (and there was never a distress incident) or because the distress incident that triggered the beacon has cleared up and assistance is no longer required. This capability is required (in ICAO document 10054, “Manual on Location of Aircraft in Distress and Flight Recorder Data Recovery”) of all ELT(DT) beacons, and it is available to the manufacturers of all second-generation beacons. To ensure that a cancellation message is not received and processed in error, the specifications require that several consecutive cancellation messages be sent by the beacon, and that more than one such message must be received before they will be processed. When the first cancellation message is received at an MCC, the MCC sets a flag and waits for another cancellation message from the same beacon. If any other message is received from that beacon, the flag is cleared, and no further action is taken. However, if further cancellation messages are received, then the MCC sends a cancellation alert to all the RCCs that have been notified of the original distress alert. Each RCC can then process this cancellation alert according to its own procedures. A-23 The specifications for the processing of cancellation message alerts are contained in section 4.2.11 (“Cancellation Message Procedures”) of document C/S A.001. The standard alert message formats (as defined in the SID and discussed in section B.5 of this Handbook) are used to transmit cancellation alert data messages. These messages are recognized by the contents of the beacon message that is contained in the incident alert message. Once a cancellation message has been recognized at an MCC, a new incident alert message, which can be identified as a cancellation message, is transmitted to every destination to which the MCC has previously sent an incident alert for that beacon. The SIT 185 message that is sent to the final SAR destination contains an explicit statement that this is a cancellation message. A.5 Message Transmission Once the alert data has been prepared in the format that is appropriate for the nature and contents of the alert, the MCC must determine the network that will be used to communicate with the selected destination. This is normally established by a configuration setting in the MCC. The formatted message string is wrapped in the header and trailer sequences that are required by the network, which may include: • an indication of the start of message (unique to each network protocol), • the addressing data appropriate to the selected destination, • a message sequence number (which can be used at the destination to ensure that no message has been lost since the previous message was sent), • information about the message priority, • any other data that may be required by (or available through) the selected communications protocol, • an indication of the end of the message packet. With this data included, the message is transmitted over the network. If the network protocol supports it, the reception of the message by the destination will be confirmed automatically by the software. Otherwise, the message is simply transmitted, and the successful reception is assumed. A.6 Data Validation A.6.1 406 MHz Alert Message Validation Section 4.2.1.1 (“Validation of Alert Message Format and Content”) of the DDP requires that each MCC should validate all incoming beacon alert messages based on the format and content of the SIT message. The flow chart in Figure 4-8 of the DDP (“406 MHz Alert Message Validation Flowchart”) illustrates the alert message validation processing. A-24 A message is considered corrupt if: • any message field is missing; or • the size of any message field is incorrect; or • a numeric message field contains non-numeric character(s); or • a space or decimal point is incorrectly placed. If the message is corrupt, then all processing of that message is suppressed. Otherwise, the message is processed according to the requirements of Table 4-4 (“406 MHz Alert Message Validation”) of the DDP. If the message is not corrupt (based on the characteristics listed above), then a further check of the contents of the essential message fields is required. These essential message fields are included in Table and are identified explicitly in Table . If the values of all of these message fields are within the allowed range (as specified in the SID), then the message can be processed; if any of these values is out-of-range, then the message is considered to be corrupt, and the processing must be suppressed. Table A-4: Essential Message Fields The Message Fields that are listed in this table are considered essential, and their contents must be evaluated to ensure that they are within the expected range before the message can be accepted as a valid message. A-25 MF \# Name Reporting facility SIT Spacecraft ID Number of Alerts with Doppler/DOA Positions Number of Alerts without Doppler/DOA Positions Source ID Local or Global Flag & Frequency Band Bias, BSDEV, & Drift TCA 14a Time of First Burst 14b Time of Last Burst Number of Points or Bursts FGB 406 Message Latitude Longitude Error Ellipse Data Residual FGB Full 406 Message Satellite IDs SGB Data The list of items that must be checked, together with the bit position of each item in the beacon message and the pass/fail criteria for each item, are contained in Table 4-6 (Protocol Validation for 406 MHz Alert Messages) of the DDP. This validation is further described in sections 4.2.1.1.4 (406 MHz FGB Message Validation) and 4.2.1.1.5 (“406 MHz SGB Message Validation”) of the DDP. The validation of the message fields that contain the beacon message data (MF \#23, 77, and 90) is based on the appropriate beacon specification. The MCC must also verify that the position reported for the beacon was visible to the satellite(s) through which the beacon data was received at the time when the detections were reported. This is done by computing the visibility circle of each satellite and confirming that the estimated position is inside that circle. See section 4.2.1.2 (“Doppler/DOA Position Footprint Validation”) of the DDP (document C/S A.001) and Appendix B.2 to Annex B (“Determining the LEOSAR Image Position and Validating the Satellite Footprint”) of the SID (document C/S A.002). Finally, the DDP requires, in section 4.2.1.4 (“Uncorroborated MEOSAR Alerts”), that the MCC make a special check for uncorroborated MEOSAR alerts; that is, any alert that has been derived from only a single beacon burst (i.e., the associated detect times per Message Fields \#14a and \#14b A-26 in document C/S A.002 are within 2.5 seconds) and from a single satellite (per Message Field \#83) for which no previous alert has been generated for this beacon activation that contains data from a different beacon burst or satellite. This is a temporary measure to eliminate the large number of spurious solutions that were reported by the first MEOLUTs developed for use with the System. A.6.2 Concept of Filtering Redundant Data and Better-Quality Alerts Although the rules described in the previous sections are generally applied, there are some exceptions that are allowed in document C/S A.001, “Cospas-Sarsat Data Distribution Plan (the DDP): • Unless continuous transmission has been requested (as described below), then redundant data (that is, repeat data for the same detection of the same beacon incident) will not be sent to any MCC or RCC. The detailed rules for determining when incident alert data is redundant are fairly complex and are described in detail in section 3.2.3.2 (“Filtering of Redundant Data”) of the DDP. • A solution that is not redundant will not be distributed unless it is a better-quality solution that any of the previously transmitted solutions. The details of this processing are described in section 4.2.4 (“Procedures to Determine Better Quality LEOSAR Alert Data for Same Beacon Event Position Conflicts”) of the DDP. • Any MCC can request continuous transmission of incident alert messages for a specified beacon or for a specified area, as explained in section 3.2.5 (“Continued Transmission after Position Confirmation”) and section 3.2.7 (“Requesting Transmission of Alerts”) of the DDP. This can be done for a known beacon, in advance of any alert being received (in support of a traveller who may have special reasons to request this monitoring), or in support of a planned test. In this case, every incident alert for the specified beacon will be sent to the requesting MCC or RCC. • Any MCC can request the suppression of incident alert messages for a specified beacon or for a specified area as explained in section 3.2.7 (“Requesting Transmission of Alerts”) of the DDP. This can be done for a known beacon, in advance of any alert being received (in support of a traveller who may have special reasons to request this monitoring), or in support of a planned test. In this case, no incident alert messages for the specified beacon will be sent to the requesting MCC or RCC. These rules are designed to prevent overloading of the communication networks and the MCC processing capabilities (and the demands on the MCC operators) when the system becomes busy. A.6.3 Event Flags The processing of an incident alert is controlled by a series of flags, as defined in section 4.2.5.4.1 (“Tests and Flag Setting for Special Processing Procedures”) of the DDP. The precise definitions of these terms are contained in that section, but the following are general descriptions of some of these flags: • SBE (Same Beacon Event): A-27 A beacon event is defined (in document C/S S.011, “Cospas-Sarsat Glossary”) as the passage of a Cospas-Sarsat satellite over an active beacon, characterized by the time of closest approach (TCA) and the satellite identification. Two LEOSAR Doppler solutions represent the same beacon event (SBE=1) if they are based on the same satellite and their TCAs are within twenty minutes of one another. Otherwise, the flag is set to 0. This flag is only used for matching two Doppler solutions; for any other matches, the flag is set to the default value (0). This flag is used to decide when a new LEOSAR Doppler solution can be used to confirm a previously received Doppler solution and to resolve the solution ambiguity, as explained in section 4.3.4.4 of this Handbook and in section C.1.2.1 of this Handbook. The distance criteria for matching the two events are described in section A.6.4 of this Handbook. • DBE (Dependent Beacon Event): Two MEOSAR DOA solutions represent a dependent beacon event (DBE) if the new solution is based on the same set of satellites (or a subset thereof) over the same time period (within thirty minutes). Once a solution has been confirmed, the criteria for a dependent beacon event are similar but somewhat different, depending on whether or not the new solution matches the confirmed solution. • PQF (Poor Quality Flag): A LEOSAR Doppler solution is of poorer quality that the previous solution if the expected error estimate indicates that the initial solution was expected to be closer to the true beacon position. The PQF is not used for a MEOSAR DOA solution. (It is always set to indicate a poorer quality solution. These flags are used to control the processing of each new incident alert message, as determined by the special processing matrices in the remaining parts of section 4.2.5.4 (“Special Processing Procedures”) of the DDP. Each of the special processing matrices is based on a particular incident status, and indicates the desired processing, based on the various combinations of processing flags and input solution status. The structure of these processing matrices is explained in section A.3 of this Handbook. A.6.4 Distance Criteria The DDP (document C/S A.001) specifies many distance criteria to be used for the automatic processing of incident alert location data: • There are separate match criteria for each combination of solution types, as defined in section 4.2.2 (“Position Matching”) of C/S A.001 and listed in Table of this Handbook. • There are distance criteria for the decision of when to transmit a better-quality position estimate for a DOA solution, as defined in section 3.2.3.2.3 (“Distribution of Alerts with Better Quality DOA Position”) of C/S A.001 and listed in Table of this Handbook. A-28 • There is a distance criterion of 100 km for the matching of interferer solutions, as defined in section 4.2.9.1 (“406 MHz Interference Data Processing”) of C/S A.001. The use of each of these criteria in the incident alert processing in the MCC is described in the DDP. In general, each distance match criterion is required to be independently configurable; this allows for future changes to individual distance match values without the need for a modification to the MCC software. If more than one position is available for the matching test, then the best match shall be used to confirm the position. These are two-dimensional distance criteria; the altitude is not to be used in computing the distance between two positions. As explained in section C.1.2.1 of this Handbook, two LEOSAR solutions that match on both sides (A- and B- positions) cannot be used to resolve the solution ambiguity. Table A-5: Solution Match Criteria This table lists the criteria that are used for matching two beacon position estimates, as defined in section 4.2.2 of C/S A.001. Solution Types Match Distance (kilometres) Doppler Doppler Doppler Encoded Encoded Encoded DOA DOA DOA Encoded DOA Doppler As defined in section 3.2.4 (“Confirmation of Beacon Positions”) of C/S A.001, the same position matching criteria listed in Table of this Handbook are used for the confirmation of a beacon position estimate. When the MCC has determined that a new solution is a better quality than a previous solution, the new message will be transmitted if it meets the criteria listed in Table of this Handbook. In addition, the EHE of the new position must be at least 50% less than the lowest EHE for all previously reported solutions. Table A-6: Better Quality Solution Criteria This table lists the criteria that are used in the determination of which of two MEOSAR solutions gives a better-quality position estimate, as defined in section 3.2.3.2.3 of C/S A.001. A-29 Solution Types Maximum Distance (nautical miles) Maximum Distance (kilometres) New Solution EHE 150.0 277.8 Minimum difference (FGB) 2.0 3.704 Minimum difference (SGB) 1.9 3.519 A.6.5 Image Position Determination As explained in section 4.2 of this Handbook, every LEOSAR Doppler solution produces two position estimates, of which one points at the real position of the beacon and the other points at an image (the reflection of the position across the satellite orbital plane. The process of determining which is the image solution (and which is, therefore, to be discarded) is called ambiguity resolution. Ambiguity resolution is explained in more detail in section C.1.2 of this Handbook. A.6.6 Satellite Footprint Verification At any given time, each satellite can only see a limited part of the surface of the Earth; this area of the Earth’s surface is the footprint of the satellite. Each location that is received by the MCC must be verified to ensure that it is consistent with the position of the satellite. That is, the location must be within the footprint that was visible to the satellite at the time when the data for that location was collected. The details of the footprint validation are described in Appendix B.2 to Annex B (“Determining the LEOSAR Image Position and Validating the Satellite Footprint”) of the SID (document C/S A.002). If a location fails the footprint validation check, then it should be flagged as unreliable, as specified in sections 4.2.1.2 (“Doppler/DOA Position Footprint Validation”) or 4.2.1.3 (“Encoded Position Footprint Validation”) of the DDP (document C/S A.001). In summary: • An independent position (Doppler or DOA location) that fails the footprint check may be used, but must be flagged as suspicious in the message that is sent out with this alert by the MCC, • An encoded location that fails the footprint check must not be used in the MCC processing of the alert. Note that, as explained in section 6.10 of this Handbook, the footprint check requires that the MCC have orbital data available for each of the satellites that is used by the Cospas-Sarsat Space Segment. A.6.7 Bit Errors The Cospas-Sarsat System includes several digital communications systems: • the uplink from the distress beacon to the satellite of the Cospas-Sarsat Space Segment, • the downlink from the spacecraft to the LUT of the Ground Segment, A-30 • the communications link from the LUT to the associated MCC, • the communications links among the MCCs that comprise the data distribution system, • the communications link from the destination MCC to the SAR destination that will finally deal with the distress situation. Any digital communications system may be subject to errors, which will result in bit errors in the data: invalid data bits that may be present in the received message. A.6.7.1 Satellite Link Errors Any bit errors that are generated in the uplink or downlink communications links through the Cospas-Sarsat spacecraft are dealt with when the beacon message is received at the LUT. The beacon specifications (documents C/S T.001, C/S T.015, and C/S T.018) all include provision for a Bose–Chaudhuri–Hocquenghem (BCH) error correcting code (ECC). The BCH codes can identify bit errors in a message, and they can be used to correct the message if the number of errors is sufficiently small (as indicated in Table ). As long as the number of bit errors is small enough, the same computations can be used to identify the bits that have been corrupted in the received message and to correct the message. The details of the computations that generate the BCH codes are described in Annex B (“BCH and CRC Calculations”) to the first- generation beacon specification (document C/S T.001) and in Appendix B (“Sample Bose- Chaudhuri-Hocquenghem Error-Correcting Code And 23 Hex ID Calculations”) to the second- generation beacon specification (document C/S T.018). Table A-7: Bit Error Detection and Correction This table indicates the number of bit errors that can be detected and corrected by the various BCH codes that are used in the Cospas-Sarsat distress beacon messages. Message Types Bit Errors Detected Corrected FGB Message FGB Extension SGB Message A.6.7.2 LUT to MCC Errors As noted in section 4.4.2.2 of this Handbook, Cospas-Sarsat does not specify the communications link between each LUT and its associated MCC. However, the MCC Performance Specification (in C/S A.005) does require (in section 5.2.1, “LUT/MCC”) that less than 0.1% of all messages be lost in transfer. It also imposes time limits for the completion of transmission of alert data from the LUT to the MCC. Most LUT to MCC communications links are digital data networks that include their own capability to detect and to correct any errors that occur during the transmission of the data from the LUT to the MCC. In practice, all MCCs meet the requirements (above) without difficulty. A-31 A.6.7.3 MCC to MCC Errors The communications links between MCCs are required to meet the specifications of the DDP (document C/S A.001) and the SID (document C/S A.002). In addition, the MCC Performance Specification (in C/S A.005) requires (in section 5.2.2, “MCC/MCC”) that less than 0.1% of all messages be lost in transfer. It also imposes time limits for the completion of transmission of alert data from the LUT to the MCC and an availability requirement for each communications link. The FTP/VPN communications links that are used by most MCCs are digital data networks that include their own capability to detect and to correct any errors that occur during the transmission of the data. In practice, most MCCs meet the requirements (above) without difficulty. However, not all parts of the world are well served by the Internet; in these areas, some MCCs have been put out of service for extended periods of time by communications failures. In areas where reliable Internet service is not available, some MCCs have chosen to use the AFTN network. This has created its own problems, as the AFTN (or AMHS) service may be slower than FTP. Also, since AFTN does not always include error detection and correction, it may be less able to meet the requirements for Cospas-Sarsat MCC to MCC communications. The selection of the communications service to be used for inter-MCC communications is a key decision in the establishment of an MCC, which must be carefully considered to ensure that the new system will meet the performance requirements for a Cospas-Sarsat MCC. A.6.7.4 MCC to RCC Errors As noted in section 4.4.2.3 of this Handbook, Cospas-Sarsat specifies the communications link between an MCC and its foreign SPOCs, but not its national RCCs. However, the MCC Performance Specification (in C/S A.005) does require (in section 5.2.3, “MCC/Non-MCC Alert Recipient”) that this link should be available for 95% of each calendar day. There are no explicit specifications for the error rate on this link; that is considered a requirement for the receiving end of the link. A.6.7.5 MCC Bit Error Processing When an MCC receives an incident alert, one of the initial steps in the processing is to validate the alert, as described in section A.1.5 of this Handbook. One of the key steps in this validation is to confirm that the beacon message, including the BCH code, is correct. If the SIT message is not valid, the MCC operator should contact the MCC that sent the message and request a re- transmission. If the beacon message cannot be corrected or is otherwise determined to be invalid, then the alert will be processed, but the data that is contained in the beacon message will not be used to control that processing. A.7 System Data Distribution System Data is the information that is required by the various components of the Cospas-Sarsat Ground Segment to ensure that they are able to perform the functions that are required of them. The System Data messages also include the narrative messages that are used to send status and A-32 other information between MCCs. Table contains a summary of the system data and of the SIT message formats and data fields that are used for the distribution of system data. (Note that the system data messages also contain many of the control and identification message fields that are listed in Table , in addition to the message fields that are listed in Table .) Table A-8: System Data This table summarizes the system message formats and the data fields that are specific to these System Messages. System Data SIT Message Numbers References Message Fields Satellite orbits 215, 216, 217 A.7.2 34, 35, 36, 85, 86 SARP Calibration 415, 417 A.7.3.1 37, 38, 38a SARR Calibration A.7.3.2 64, 65, 66 Spacecraft Instrument Control Messages 416, 425, 435, 445, 515, 525, 535, 545 A.7.4 39, 40, 41 Status and narrative 605, 915 A.7.5 Beacon registration 925, 926, 927 A.7.6 94, 95, 96, 97 Each MCC normally maintains a set of orbital and calibration data for each of the satellites that is tracked by the Cospas-Sarsat Ground Segment. This data is distributed through the MCC network by the MCC of the Space Segment Provider that is responsible for that part of the Cospas-Sarsat Space Segment. The MCC may not actually use this data internally, but it is responsible to ensure that its associated LUTs have all of the necessary data kept up to date at all times. When an MCC receives a System Data Message that contains satellite orbit or calibration data, it should validate the data (by comparing it with the data it already has). If the new data is within an acceptable tolerance of the old data, then the MCC should accept the new data. If the new data is significantly different from the old data, then the MCC operator should be notified. The operator will then evaluate the difference and determine whether the new or old data should be used. Normally, if the associated LUTs have been using the old data and producing results that are within the accepted tolerances (as determined by the QMS monitoring), then the MCC should continue to use the old data. However, if the data produced by the LUTs has been of poor quality, then the operator should force the MCC to use (and send to its associated LUTs) the new System Data. Where the text below indicates that the System Data is to be forwarded to associated LUTs, this only applies if the MCC has one or more associated LUTs of the indicated type. A.7.1 System Data SIT Message Formats The System Data Messages that are listed in Table are described in more detail in the following sections of this Handbook. A-33 A.7.2 Satellite Orbit Messages There are several different message formats for the transmission of satellite orbital data: • The SIT 215 messages contain the orbit data for the LEOSAR satellites, in the form of position and velocity vectors. They are sent to all MCCs for the normal distribution of this data. They should be sent by each MCC to all of its associated LEOLUTs. They may be used, as required, by each LEOLUT, to update its orbit data. However, if the LEOLUT is automatically updating its own internal orbit data, based on the data received from reference beacons and the satellite downlink carrier, then it may use the data that it receives from the MCC only to verify the internal orbit data. • The SIT 216 messages contain the orbit data for the LEOSAR satellites, in the form of position and velocity vectors. They are sent to all MCCs for the distribution of LEOSAR satellite orbital elements after a satellite manoeuvre. They should be sent by each MCC to all of its associated LEOLUTs. Regardless of the results of the orbit data validation in the MCC, these elements are to be used by each LEOLUT to update its orbit data, to ensure that the orbits have been correctly updated after the completion of the manoeuvre. • The SIT 217 messages contain the orbit data for the MEOSAR (or any other) satellites, in the Two-Line Element (TLE) format developed by the North American Air Defence Command (NORAD). They are sent to all MCCs for the normal distribution of this data. They should be sent by each MCC to all of its associated MEOLUTs. They may be used, as required, by each MEOLUT, to update its orbit data. However, if the MEOLUT is automatically updating its own internal orbit data, based on the data received in the GNSS navigation downlink signals, then it may use the data that it receives from the MCC only to verify the internal orbit data. Although the GEOLUT systems may not require the use of satellite orbital data, this data may be distributed in the SIT 217 message format and forwarded by each MCC to its associated GEOLUTs. The orbit data in these messages may be formatted as either of: • position and velocity coordinates in a three-dimensional (X-Y-Z) Euclidean coordinate system, • a variation of the classical Keplerian orbit elements, in the NORAD Two-Line Element (TLE) format. The SIT message formats and the data message fields that are used to transmit the orbit data are described in more detail in section B.6.1 of this Handbook. A.7.2.1 Position and Velocity Vectors The position and velocity vectors provide the actual position and velocity of the satellite at a specific point in time (the orbit epoch). This information is enough to enable the MCC (or LUT) system to compute the position of the satellite at any time in the past or future (subject to the accuracy limitations of the computer system). A-34 A.7.2.2 NORAD Two-Line Elements The Two-Line Elements (TLE) are a format for the orbital data of a satellite in orbit around the Earth. It was developed in support of the simplified perturbations models, a set of mathematical models (SGP, SGP4, SDP4, SGP8 and SDP8) that are used to calculate the orbital state vectors of satellites and space debris relative to the Earth-centred inertial coordinate system. [The acronyms represent the Simplified General Perturbations (SGP) model for near earth objects and Simplified Deep Space Perturbations (SDP) for more distant objects.] The TLE format is used by the North American Aerospace Defence Command (NORAD) to track objects in Earth orbit. Because many of the values that are included in the TLE format do not change over time, they are easier to use in orbit computation models than the position and velocity vectors. It is possible to convert between the different sets of orbital elements, but the use of the TLE data simplifies the processing that has to be done in the computer systems. The TLE format has come to be accepted as a de facto standard for the distribution of the orbital elements of an object in orbit around the Earth. The formatting and use of the TLE orbital elements in the SIT messages from an MCC are described in more detail in section B.6.1.2 of this Handbook. A.7.2.3 Orbit Reference Coordinate System When MEOLUTs are linked in a network, they exchange time and frequency readings in a set of text files that are encoded in the Extensible Mark-up Language (XML). Although these files are not in the SIT message formats that are used between MCCs, they are also specified in the SID (document C/S A.002), and they also make use of the data in the Message Formats that are defined in the SID. In order to ensure that accuracy of the data that is exchanged between MEOLUTs, these XML files may also need to include the related satellite orbit data. The orbit data, as position and velocity vectors, may be in either of two coordinate systems: • an Earth-Centred Earth-Fixed coordinate system that rotates with the Earth, • an Earth-Centred Inertial coordinate system that does not rotate with the Earth. Message Field 87 is included in the XML file to specify which coordinate system is used for the orbit data in that file. A.7.3 System Calibration To enable the LUT and MCC systems to compute the beacon location estimates, and to achieve the accuracy that is desired of the system, certain items of calibration data are also distributed through the MCC network, as described in the following sections. A.7.3.1 SARP Calibration As explained in section 6.10.4 of this Handbook, the LEOLUTs require calibration data to interpret the time and frequency measurements that are received from the Search and Rescue Processor A-35 (SARP) instruments on the LEOSAR Sarsat spacecraft. Every week, the French MCC distributes this SARP calibration data to all MCCs. When an MCC receives a SARP Calibration message, it should validate the calibration data and then forward it to its associated LEOLUTs. Each LEOLUT may then use this data to validate its own calibration, and to update it as necessary. A.7.3.2 SARR Calibration As explained in section 6.10.5 of this Handbook, the LEOLUTs should also receive calibration data so that they can accurately report the frequency measurements that are received from the Search and Rescue Processor (SARP) instruments on the LEOSAR Sarsat spacecraft. Every month, the Canadian MCC distributes this SARR calibration data to all MCCs. When an MCC receives a SARR Calibration message, it should validate the calibration data and then forward it to its associated LEOLUTs. Each LEOLUT may then use this data to validate its own calibration, and to update it as necessary. A.7.4 Spacecraft Instrument Control Messages The spacecraft instrument control messages are specialized messages that are used by the Space Segment Providers for the control of the Search and Rescue instruments on the satellites of the Cospas-Sarsat Space Segment. The details of the message formats and the message fields that they contain are described in section B.6.4 of this Handbook. These message formats are not used by other MCCs. A.7.5 System Status and Narrative Messages The status and narrative messages are used to distribute information that may be of interest to the Ground Segment Providers in the Cospas-Sarsat System. These messages use the same control data message fields as the other SIT messages, as listed in Table . However, the actual information in each message is in Message Field \#41, which is essentially a free-format stream of text characters that can be read by the operator at the receiving facility. The message text is divided into a sequence of lines, each of which has fewer than 70 characters, and which is terminated by an end-of-line sequence (carriage return – carriage return – line feed). The only limitation on the contents of these messages is the length of the message: • each message must contain no more than 25,000 characters. • for a message that is to be transmitted over an AFTN communications network, the message must not exceed 2100 characters in total, and the content of the SIT message inserted into the AFTN message must not be more than 1800 characters. In addition, the text sequence is terminated by the characters “QQQQ”; for obvious reasons, this sequence may not appear anywhere else in the message. A-36 A.7.5.1 System Status The SIT 605 message is a system status message that is distributed to all MCCs. A SIT 605 message may be generated automatically by the MCC computer system in response to a predefined circumstance, or it may be entered into the system by the MCC operator. Uniquely in these messages, the destination facility code in MF \#5 is not used to identify the final destination to which the message should be sent. Unlike other SIT messages, this message field is used to indicate the immediate next destination. The originating facility sends the message to its nodal MCC, from which it is then to be forwarded to all nodal MCCs. Each nodal MCC modifies MF \#5 and distributes this message to all MCCs within its Data Distribution Region (DDR). In this way, the status information is rapidly distributed to every MCC in the network. A.7.5.2 Narrative Messages The SIT 915 message is a simple narrative message. It is generated, usually by operator entry, at the source facility and it is sent (through the MCC data distribution network) to the destination facility. A.7.6 Beacon Registration Data Every country that participates in the International Maritime Organization (IMO) or the International Civil Aviation Organization (ICAO) is required, by the terms of their participation in those organizations, to maintain a registry of all distress beacons that are identified with their country code in the beacon message. The Cospas-Sarsat MCC that serves the area that includes the country must have access to the national beacon registration database and must support requests for the registration information from any other MCC. This support includes the ability to respond to requests, from the responsible authorities, for information about any beacon with a country code in the MCC Service Area. As each request is received, the MCC must forward the request for information to the appropriate national beacon registry and must return the information retrieved to the requesting authority. For any country that does not maintain its own beacon registry for a particular type of distress beacon, the Cospas-Sarsat Programme maintains the International Beacon Registration Database (IBRD), which will manage the registration records of the specified type of beacons for that country. Access to the IBRD is available to all Cospas-Sarsat MCCs (and to all authorized SAR authorities). - END OF ANNEX A - B-1 ANNEX B: DESCRIPTION OF SIT MESSAGES One of the most important tasks of an MCC is to distribute the information that is used in the Cospas-Sarsat System, especially the incident alert data that is generated when a message from a Cospas-Sarsat distress beacon is received by the Ground Segment of the System. This information is distributed to the appropriate destination, as described in Annex A of this Handbook, in one of the message formats that are specified in the document C/S A.002, “Cospas-Sarsat Standard Interface Description” (the SID). This Annex is intended to provide additional information about the structure of these messages and about the meaning of some of the individual data items that they may contain. The following annexes to the SID contain the detailed specifications for the formats of the messages that are used in the Cospas-Sarsat data distribution network: • ANNEX A “Subject Indicator Types (SITs)”, • ANNEX B “Message Field Description”, • ANNEX C “Message Content by SIT”, • ANNEX D “Useful Information for Standard Message Formats between MCC and RCC”. Some of the contents of these annexes to the SID is explained further in this Annex of this Handbook. The SID includes a special set of message formats, identified as SIT number 185, which is used to send the incident alert data to a Search and Rescue Point of Contact (SPOC). Although these formats are officially designated for transmission to a SPOC, the same formats are usually used to send the incident alert information to the national Rescue Coordination Centres (RCCs) that are associated with an MCC. The information that is contained in these SIT 185 messages is explained further in document C/S G.007, “Handbook on Distress Alert Messages for Rescue Coordination Centres (RCCs), Search and Rescue Points of Contact (SPOCs) and IMO Ship Security Competent Authorities”. The explanation of the SIT 185 messages is not duplicated in this annex. B.1 International Character Set As per section 4.2 (“Character Set”) of document C/S A.002, “Cospas-Sarsat Mission Control Centres Standard Interface Description”, and as listed in the tables in that section: • Table 4.1 “International Alphabet No.5 (IA5))”, • Table 4.2 “International Telegraph Alphabet No.2 (ITA2))”, • Table 4.3 “Equivalents for Translation between International Telegraph Alphabet No.2 and International Alphabet No.5”, B-2 The contents of every MCC message are limited to the characters that are included in both ITA2 and IA5; no other characters are accepted as valid in the text of a message that is generated and transmitted by an MCC. The octothorpe character (“\#”), which is used in some communications networks as a control character, is not permitted in an MCC message. Some characters that are required in MCC messages are not available in the permitted character set; those characters are replaced by specific character sequences, as listed in Table . Note that these restrictions apply to all messages, regardless of the communications network that is used. Table B-1: Replacement Character Sequences The characters listed in the first column of this table must be replaced by the indicated character sequence in an MCC message. Character Description Replacement Sequence @ “At” sign (AT) % Percent sign PERCENT \_ Underscore character (UNDERSCORE) B.2 Message Subject Indicator Types Every message that is generated and transmitted by an MCC to another MCC is identified by a Subject Indicator Type (SIT) code number, which defines the format of the message. All of the valid SIT codes, and the associated formats, are described in the SID. Most of the message formats that are defined in the SID are designed for automated processing, so that they can be read and processed by the computer systems in an MCC. The major exception to this rule is the SIT 185 messages that are sent to RCCs and SPOCs, which are less rigidly constrained, and are designed for a human reader. As noted above, the contents of these messages are described in C/S G.007. Because these messages are created from the data that is received by an MCC in the other SIT formatted messages, there is much overlap in the contents of these messages. The intent of this annex is not to reproduce the information from C/S G.007, but to provide additional information about the meaning of some of the individual data items that may be contained in all of the incident alert messages. The SIT message numbers that are used to distribute the incident alert data between MCCs are organized into blocks, according to the type of data that is in the message, as identified in Table 2, Table 3, and Table . Table B-2: Alert Messages by Beacon Generation The only exception to the assignment of these blocks of numbers is the SIT185 message, which may be used for an alert message from either an FGB or an SGB. B-3 SIT Message Numbers Description 100 - 199 Formats for First-Generation Beacon (FGB) incident alert messages 300 - 399 Formats for Second-Generation Beacon (SGB) incident alert messages Table B-3: LEOSAR and GEOSAR Alert Messages Note that, for those messages with the superscript on the location type (“Doppler1”), the message may (or may not) also include an encoded location. Note also that the LEOSAR system is not expected to support the Second-Generation Beacons; the SGB formats that have “LEO/GEO” will only be supported by the GEOSAR system. SIT Message Numbers Satellite System Description Location Data FGB SGB LEO/GEO Interferer Alert Doppler LEO/GEO Incident Alert No Doppler LEO/GEO Conflict Alert Encoded only LEO/GEO Position Confirmation Alert Encoded only LEO/GEO Incident Alert Doppler1 LEO Conflict Alert Doppler1 LEO Position Confirmation Alert Doppler1 LEO/GEO Notification of Country of Registry (NOCR) Encoded only LEO/GEO Notification of Country of Registry (NOCR) Doppler1 LEO/GEO Notification of Return Link Service Provider Encoded only LEO/GEO Notification of Return Link Service Provider Doppler1 Table B-4: MEOSAR Alert Messages Note that, for those messages with the superscript on the location type (“DOA1”), the message may (or may not) also include an encoded location. B-4 SIT Message Numbers Satellite System Description Location Data FGB SGB MEO Notification of Country of Registry (NOCR) Encoded only MEO Notification of Country of Registry (NOCR) DOA1 MEO Notification of Return Link Service Provider Encoded only MEO Notification of Return Link Service Provider DOA1 MEO Interferer Alert (DOA location) DOA MEO Incident Alert No DOA MEO Conflict Alert Encoded only MEO Position Confirmation Alert Encoded only MEO Incident Alert DOA1 MEO Conflict Alert DOA1 MEO Position Confirmation Alert DOA1 B.3 Message Fields Each SIT message format is defined as a series of Message Fields. Each message field is identified by a Message Field Number (MF\#) and is described in the SID. In a SIT message, the message fields are normally (but not always) separated by either a slash (“/”) or an end-of-line sequence (carriage return, carriage return, line feed: “cr-cr-lf”). The message fields are described in detail in Annex B of the SID. That annex contains: • Table B.1 (“Message Field Description”), in which the format of each message field is specified, and • Appendix B.1 to Annex B (“Message Field Definition”), in which the meaning and use of each message field is defined and explained. The next section explains how the message field descriptions are specified in Table B.1 of the SID. The following sections identify the Message Fields that are used for specific functions in the messages that are generated and transmitted by an MCC. The SID also contains an Annex C (“Message Content by SIT”), which identifies the message fields (by MF\#) that are contained in each of the SIT messages (by SIT number). This Annex C also contains a collection of sample messages of various SIT numbers. Unless the specifications in the SID leave room for ambiguity, the individual message fields are listed, but not further described, in this Annex to the Handbook. B-5 B.3.1 Message Field Identification Each message field is identified by a message field number (MF\#). The MF \#is used in the SID to specify every reference to that message field. Specifically, the descriptions of the message fields in Table B.1 (“Message Field Description”) of the SID and the definitions of the message fields in Appendix B.1 to Annex B (“Message Field Definition”) are both listed in the sequence of message field numbers. A message field number is normally a two-digit number (from 01 to 99). However, there are several message fields (especially – but not only – those that are used in the SIT 185 message) that have many variants; each of these variants is identified by a letter that is placed after the two-digit number. B.3.2 Message Field Descriptions Each of the message field descriptions in Table B.1 of the SID contains four entries: • The message field number (MF\#), • The name of the field, • A brief description of the contents of the field, • The character text: a template of the character sequence that may be used in the field. The meaning and use of each of these entries is explained in sections 2.1 to 2.4, respectively, of Annex B of the SID. These entries for a set of four columns in the table. The meanings of the first two columns are relatively clear. The description of each message field explains the information that the field contains, including: • The meaning of the data, • The range of values that may be placed into the field, • The default values to be used when there is no proper value available for the required data. The template in the fourth column (character text) may indicate any of: • the exact text to be placed in the field - represented as an upper-case letter character, • any valid character - represented as the letter “a”, - see section B.1 of this handbook • any valid hexadecimal character - represented as the letter “h”, B-6 - must be: ▪ a digit (0 to 9) or, ▪ an upper-case letter (A to F, representing 10 to 15). • a sign symbol - represented as the letter “s” - must be the character “+” (plus sign) or the character “-” (minus sign) • any decimal digit - represented as the letter “n”, - must be a digit (0 to 9). • a blank space character - represented as the letter “b”, - must be the blank space character (“ ”). Every message field is described in an entry in the Table B.1 of the SID. B.4 Lists of Message Fields The subsections of this section of this annex list and explain the message fields that are specified in the SID. Where the explanation of the meaning and format of the message field in Table B-1 (“Message Field Description”) or in Appendix B.1 to Annex B (“Message Field Definition”) of the SID are sufficient, no further explanation is provided here. However, in cases where the specifications do not include enough information, additional explanation of the message field is provided in the subsections below. B.4.1 Control Fields Every SIT message includes some of the control fields that are listed in Table . Table B-5: Message Control Fields The control message fields are used to indicate the beginning and end of each SIT message or of a complete message. A spare data field is a field that has been reserved but is not currently being used in any SIT message. B-7 Message Field Number Name Message Number Reporting Facility Message Transmit Time SIT Destination End of SIT End of Message End of Message (SIT 185) Spare Data The message number in MF \#1 contains two items: • The first item is the sequence number of this message. This number is unique and sequential for each destination. In the SID, Appendix B.3 to Annex B (“Suggested Algorithm for Message Sequence Tracking”) describes an algorithm that can be used to identify any messages that are missed, by tracking the sequence numbers of messages as they are received at an MCC. • The second part of the field is usually 00000; however, if this is a re-transmission of the message, the second part of the field is the message number of the original message. The reporting facility in MF \#2 identifies the system that sent this message to this MCC; it may be either of: • An MCC identifier, • A LUT identifier. The SID simply refers to the Cospas-Sarsat website, which has lists of the MCC numbers and the LUT numbers. An MCC identifier or a LUT identifier is a four-digit number built from the (3-digit) country code of the Ground Segment Provider, with a single digit to identify the specific system: • The MCC is identified by a zero (“0”) as the final character. • Each LUT is identified by a single digit from 1 to 9, that identifies the LUT within the country. To find the identifier for a specific reporting facility: The MCCs are listed under the tab: <“PLEASE SELECT A CONTACT TYPE -” > then <“MISSION CONTROL CENTERS”>. Scroll down to the MCC of interest, and then click on <“DETAILS”>. The MCC identifier is listed after “MCC Code”. B-8 • The LEOLUTs and GEOLUTs are listed under the <“SYSTEM”> tab: under “Detailed LEOSAR/GEOSAR System Description”, select <“LIST OF LEOLUTS/GEOLUTS”>. In the list, the LUT identifier is listed in the column “LUT Code”. • The MEOLUTs are listed under the <“SYSTEM”> tab: under “MEOLUT Configuration”. The destination of a message may be either an MCC identifier or a LUT identifier (see above). The SIT 185 message may be sent to other destinations; refer to C/S G.007 for more information about the SIT 185 message. B.4.2 Beacon Identification and Beacon Message Each incident alert message contains one or more of the data fields listed in Table , which include the beacon identification and the actual beacon message data (in hexadecimal format). Table B-6: Beacon Identification and Message Fields These message fields contain the beacon message data or the identification data fields that are contained in the message that is transmitted by the distress beacon. Message Field Number Name Size (hex digits) Beacon ID FGB 406 Message FGB Full 406 Message SGB Data 23-Hex Beacon ID Beacon Data Field Up to 64 per line The details of the beacon messages and the beacon identifier formats are available in the Beacon Specifications (documents C/S T.001, C/S T.015, and C/S T.018). B.4.3 Solution Data Each incident alert message may contain one or more of the solution data fields listed in Table . Most of the message fields that are listed in this table are explained elsewhere in this Handbook; the entries in the column “Reference” point to these explanations. The reference entry is “SID” if there is no explanation in this Handbook to supplement the information in the SID. Table B-7: Solution Data Message Fields These message fields contain the solution data generated by the LEOSAR Doppler or MEOSAR DOA processing that generates the independent location data for the beacon alert. These data items are used in the Cospas-Sarsat incident alert data messages. The table does not include the message fields that are designated for the SIT 185 messages. B-9 Data Item MF\# System Reference Spacecraft ID All B.4.3.1 Orbit Number All B.4.3.2 Number of Alerts with Doppler/DOA positions All SID Number of Alerts without Doppler/DOA positions All SID Source ID All B.4.3.2 Local or Global Flag and Frequency Band LEOSAR B.4.3.4 Solution Frequency: Bias, BSDev, & Drift LEOSAR, GEOSAR B.4.3.5 TCA (Time of Closest Approach) or Time of Transmission (first or last burst) All B.4.3.6 Window Factor LEOSAR C.1.6 Number of Iterations LEOSAR, GEOSAR C.1.1.1 CTA (Cross-Track Angle of Doppler solution) LEOSAR C.1.4 Secondary Source ID LEOSAR & GEOSAR B.4.3.2 Number of Sidebands LEOSAR B.5.12.1 Sweep Period and Standard Deviation LEOSAR B.5.12.2 Number of Points or Bursts All B.4.3.7 Beacon Identifier 22, 92 All B.4.2 Beacon Message 23, 77 (FGB) (SGB) All B.4.2 DDR/Service Area and Position Status Flag All SID Latitude All A.4.2.1 Longitude All A.4.2.1 Error Ellipse LEOSAR C.5.1 Probability LEOSAR C.1.2.1 Next Time of Visibility LEOSAR C.1.8 Confidence Factor (CF) All C.5.3 Data Residual LEOSAR SID Antenna ID MEOSAR SID C/N0 MEOSAR SID Bit Rate MEOSAR SID B-10 Data Item MF\# System Reference DOA Quality Factor MEOSAR C.2.5 Average Carrier to Noise Ratio MEOSAR SID Networked Antennas MEOSAR C.2.4.1 Antennas MEOSAR SID Altitude MEOSAR A.4.2.1 Satellite IDs MEOSAR SID Quality Indicator MEOSAR C.2.5 Number of Packets MEOSAR SID Expected Horizontal Error MEOSAR C.2.5 MEOSAR Antenna IDs MEOSAR SID B.4.3.1 Spacecraft Identification A spacecraft Identification Code in MF \#6 is a three-digit decimal number that is assigned to each of the spacecraft of the Cospas-Sarsat Space Segment. The spacecraft Identification Codes are divided into blocks, as listed in the entry for MF \#6 in Table B.1 of the SID. These blocks of numbers are also listed, with some additional information about the spacecraft, in Table of this Handbook. Table B-8: Spacecraft Identification Codes The LEOSAR and GEOSAR satellites have been numbered in sequence, as they were launched and commissioned. For the MEOSAR satellites, the sequence number for an individual spacecraft within each given range corresponds to the Pseudo-Random Noise number for that spacecraft. Space Segment Constellation Numbers Space Segment Operator LEOSAR Sarsat 001 - 099 Platform provided by USA SARR provided by Canada SARP provided by France LEOSAR Cospas 101 - 199 Russian Federation GEOSAR GOES 201 - 220 USA GEOSAR Electro-L & Louch-5 221 - 240 Russian Federation GEOSAR INSAT 241 - 260 India GEOSAR MSG 261 - 280 European Commission MEOSAR SAR/GPS 300 - 399 Platform provided by USA SARR provided by Canada MEOSAR SAR/Galileo 400 - 499 European Commission MEOSAR SAR/Glonass 500 - 599 Russian Federation B-11 B.4.3.2 Orbit Number The orbit number is the sequence number that counts the number of times that the satellite has gone around the world. It starts at one and increments by one each time the satellite completes an orbit (by crossing the equator in a northward direction). The orbit number is limited to five decimal digits. If the number exceeds 99,999, then only the last five digits of the actual orbit number are used. For example, after the satellite has completed one hundred thousand revolutions around the Earth (and is on its 100,001st orbit), the orbit number is provided as “00001”. B.4.3.3 Source Identifier The Source Identifier in MF \#11 is the identifier of the LUT that produced this alert: • For a LEOSAR solution, it is the LEOLUT identifier. • For a MEOSAR solution, it is the MEOLUT identifier. For a solution that was produced by the LEOSAR combined LEO-GEO processing, there is also a Secondary Source Identifier, MF \#18, which is the identifier of the GEOLUT that contributed data for the solution. Each of these Source Identifier codes is a LUT identifier, as described in section B.4.1 of this Handbook. B.4.3.4 Frequency Band MF \#12 contains two separate items: • The Local (“+” sign) or Global (“-” sign) flag indicates whether this alert is based on data collected by the LUT in Local mode or in Global mode. For the LEOSAR system, the values may be either “+” or “-”, as appropriate for the A-solution in the message. For the MEOSAR and GEOSAR systems, the alert is always based on Local mode (“+”) data. • The frequency band code is a one-digit decimal number that may be any of the values listed in the in the entry for MF \#12 in Table B.1 of the SID. For a 406 MHz interferer solution, the Frequency Band should be set to “+4”. The frequency band values 1, 2, and 3 were originally assigned for 121.5 MHz and 243.0 MHz solutions. Since the termination of processing of those bands, these values are no longer used. B.4.3.5 Solution Frequency The solution frequency data in MF \#13 consists of three separate sub-fields, separated by blank spaces: • The frequency bias is the offset, expressed in Hertz (Hz), of the frequency that has been computed by the LUT for this beacon as a part of its solution processing. B-12 • The bias standard deviation is the standard deviation (in Hz) of the offset of the frequency measurements from the theoretical curve that was used in the solution processing to determine the beacon location. • The drift is the estimated rate of change of the beacon frequency over time (in Hz/minute) during the period of the data that was used to determine the solution. For all of these fields, the default value is used if no data is available or if the value of the parameter is outside the permitted range. B.4.3.6 Time The time in MF \#14 is: • For a LEOSAR solution, the Time of Closest Approach of the satellite to the beacon, as described in section C.1.1.1 of this Handbook. • For a MEOSAR solution, the time associated with this solution, computed as the average of all the time of arrival measurements. • For a GEOSAR solution, the time of the first beacon message processed for this alert. The times of the first and last burst received for a MEOSAR DOA solution are provided separately (as MF \#14a and MF \#14b, respectively). B.4.3.7 Number of Points or Bursts The number of points that are used to generate a solution in a LUT is reported differently for each type of LUT: • LEOLUT This is the number of unique time-frequency pairs that are used to compute the Doppler A-solution. For combined LEO-GEO processing, only the number of LEOSAR points are included in this count. • MEOLUT This is the number of different beacon transmissions (bursts) that were used to generate a multi-burst DOA solution. • GEOLUT Until the message is confirmed, this is always reported as 1. After confirmation, this is the number of independent integrations that produced the reported beacon message. In each case, the number is reported in MF \#21. B.4.4 Solution Quality Data Most of the incident alert messages will contain one or more of the solution quality data fields, which are listed in Table and identified explicitly in Table . The specific fields that are used will depend on the nature of the solution that is reported in the message, as indicated in Table 7. B-13 Table B-9: Solution Quality Data Message Fields These message fields provide information about the quality or accuracy of the independent location data that is generated by the LUT processing. Message Field Number Name Solution Frequency: Bias, BSDev, & Drift Window Factor Number of iterations Error Ellipse Probability Confidence Factor Data Residuals, StdDev, & Trend Quality Indicator Expected Horizontal Error B.4.5 Message Fields for SIT 185 Messages The message data fields, MF \#45 to MF \#62, are defined for use in the human-readable SIT 185 incident alert messages. These SIT 185 messages, and the contents of the message data fields that are used in them, are described in more detail in document C/S G.007, “Handbook on Distress Alert Messages for Rescue Coordination Centres (RCCs), Search and Rescue Points of Contact (SPOCs) and IMO Ship Security Competent Authorities”. They are not explained further in this MCC Handbook. B.5 Incident Alert Messages Most of the message and beacon identification data is clearly defined in the SID (document C/S A.002) or in the beacon specification document (document C/S T.001, C/S T.015, or C/S T.018, as appropriate). However, the beacon location data, which may be generated in the beacon itself or may be computed as an independent location by a Cospas-Sarsat Local User Terminal (LUT), may require further explanation, as provided in the following sections of this Handbook. In all cases, the position estimate that is generated by the Cospas-Sarsat System is only an estimate. In general, the solution data provided by the Cospas-Sarsat LUTs (or by the data encoded in the beacon message) is accurate. However, it is based on measured values which are all subject to the possibility of error, and there is, therefore, always the possibility that the solution is not accurate. Each of the different solution processing algorithms that are used by the Cospas-Sarsat LUTs generates an estimate of the accuracy of the solution that it produces; these accuracy estimates are explained in sections C.5 and C.6 of this Handbook. B-14 As noted in the following sections, the format of the alert messages that are generated in each situation depends on the type of beacon that is detected: • The formats for first-generation beacon (FGB) alerts are SIT numbers between 100 and 199. • The formats for second-generation beacon (SGB) alerts are SIT numbers between 300 and 399. The only exception is the SIT 185 message format, which is used for both FGB and SGB alerts. B.5.1 Unlocated Alerts An unlocated alert is an alert that does not include any location data for the beacon. This may be an alert from the GEOSAR system, which does not produce an independent location estimate, or it may be from the LEOSAR or the MEOSAR system, when the LUT did not receive enough data from the beacon to generate an independent location estimate. An unlocated alert is distributed in the SIT 121 (FGB) or SIT 321 (SGB) message format. The message fields that are contained in these messages are listed in Table 5, Table 6, and Table 7 in section B.4 of this Handbook. B.5.2 Encoded Location Alert An encoded location alert is generated for a beacon that can determine its own position and encode the location data in the transmitted beacon message. If the encoded location data is received successfully by the LUT, then that data is available in the incident alert message that is generated by the MCC. The encoded location data is not formatted into the SIT message in a separate message field; it is contained in the beacon message in one of the message fields listed in Table 6 of this Handbook. An encoded location alert is distributed in any of the SIT message formats listed in Table in section B.2 of this Handbook. The message fields that are contained in these messages are listed in Table 5, Table 6, and Table in section B.4 of this Handbook. B.5.3 Independent Location Alert The LEOLUTs and MEOLUTs are both capable of computing estimates of the locations of the beacons from which they receive signals. These are called independent location estimates; they are independent of the location data that is received in the beacon message. The independent location data is distributed in many of the different SIT message formats that are listed in Table and Table 4 in section B.2 of this Handbook. B-15 B.5.3.1 Doppler Location Alert The Doppler solution processing that is performed by the LEOLUTs normally generates two distinct position estimates: one that is the correct location, and another that is the image of that location, reflected in the plane of the satellite orbit. The LEOLUT also generates a value for the probability that each of these estimates is the correct location. However, to resolve the ambiguity between these locations and to determine which is correct, the MCC usually must compare the location estimates from at least two independent sources and find a match that confirms one position. Based on the known satellite orbit information available to the MCC, the MCC can also determine when the next satellite pass over each estimated position is expected to happen. With this information, the MCC can include, in the incident alert message, the Time of Next Visibility of the estimated location; this information may assist the RCC to determine whether or not to begin a search and rescue operation immediately, or to wait until they have confirmation of one of the estimated beacon positions. When the beacon is first detected, and before the ambiguity can be resolved, the MCC sends a Doppler solution message that contains both position estimates (and the estimated probability for the A position). This provides the RCC with the information that the beacon has been activated. Using the contact information in the beacon register, the RCC may be able to determine if there is a true distress incident or if this is a false alarm. They may also receive enough information to immediately resolve the position ambiguity, and to initiate the search and rescue operations. Independent sources of location data may be any of: • two Doppler position estimates based on different satellite passes in significantly different orbital planes, • a LEOSAR Doppler position estimate and a MEOSAR DOA position estimate, • a LEOSAR Doppler position estimate and the position from the location data that is encoded in the beacon message, • a LEOSAR Doppler position estimate and a position estimate received from any other independent source (such as, for example, an overflying airplane). While most of these location data estimates can be processed and the ambiguity resolved automatically by the MCC computer system, the last situation can often be resolved only by manual intervention by the MCC operator. When a solution is confirmed by a match within a specified tolerance, a separate confirmation message (in a distinct SIT message format) is sent out by the MCC. The data in this message is used to inform the RCC when the ambiguity is resolved. Once the location has been confirmed, all future alert messages will be based on this beacon position. When a new solution is received with a position that matches (within a defined tolerance) the confirmed position, then a new alert message will be transmitted, to confirm that the beacon is still B-16 active. For a beacon that is moving (for example, drifting at sea), this also provides information about the changing position of the beacon. When the new position is significantly different from the confirmed position, then a position conflict message is transmitted. This identifies the possibility that there may be some concern about the identification of the confirmed location: • The original position estimate may not be correct. • The confirmation may have identified the image solution instead of the correct position estimate. (While rare, this can happen.). • The beacon may be moving too rapidly for a single position estimate to define its position accurately over a period of time. With this knowledge, the MCC or RCC personnel can review the known information about the distress incident, and decide what action is appropriate for the continued search and rescue operation. B.5.3.2 Difference of Arrival Location Alert For each Difference of Arrival (DOA) location, the MCC is provided with the value of an Expected Horizontal Error (EHE) (MF \#89), which will be forwarded in the incident alert message to the RCC or SPOC. This value is the radius of the circle centered on the DOA location that should contain the true beacon location with a 95% probability. In other words, there is a 95% probability that the location error, which is defined as the distance between the DOA location and the actual beacon location, is lower than the EHE value. The EHE is explained in more detail in section C.5.2 in ANNEX C of this Handbook. B.5.4 Special Message Formats There are a number of special message formats that are required to support the distribution of incident alert data in special circumstances. These circumstances, and the message formats that are used to distribute the alert data in each circumstance, are described in the following sections of this annex. Several of these circumstances require unique message formats for the alerts. Table 10 identifies the various circumstances when such messages may be required and lists the SIT message numbers that are used in each case, as appropriate depending on the circumstances. Table B-10: Special Alert Message Formats The SIT message formats listed in this table may be used to transmit a confirmed alert message. Subsystem Beacon Description Confirmed Alert Conflict Alert NOCR RLS LEOSAR FGB Encoded position only B-17 Subsystem Beacon Description Confirmed Alert Conflict Alert NOCR RLS LEOSAR FGB Doppler position MEOSAR FGB Encoded position only MEOSAR FGB DOA position GEOSAR SGB Encoded position only MEOSAR SGB Encoded position only MEOSAR SGB DOA position B.5.5 Unconfirmed Location Alert Although an alert message is distributed immediately when there is information available, the MCC goes through a process of checking subsequent messages that relate to the same beacon to confirm the detection and location of the beacon. This process is described in section A.4.3 of this Handbook. The alert message that is distributed before the incident has been confirmed is called an unconfirmed location alert. This alert contains all of the information that is available for this incident alert; however, the SIT number identifies it as an unconfirmed alert. Unconfirmed alert messages may be sent in most of the SIT formats that are listed in Table and Table in section B.2 of this Handbook. B.5.6 Confirmed Location Alert After the alert confirmation process, as described in section A.4.3 of this Handbook, has been completed (and the beacon solution has been confirmed), a new alert for the same beacon will be distributed as a confirmed alert. A confirmed alert message is sent in one of the SIT message formats listed in the column “Confirmed Alert” in Table , above. B.5.7 Conflict Solution Alert Each new alert is compared to the previous alerts for the same beacon in the alert confirmation process, as described in section A.4.3 of this Handbook: • Before the alert has been confirmed, if the new solution does not match any previous solution, then the new solution is flagged as a conflict solution, and an alert is sent to inform the recipients of this. B-18 • After the alert has been confirmed, if the new solution does not match the confirmed location, then the new solution is flagged as a conflict solution, and an alert is sent to inform the recipients of this. In each such case, the conflict alert is sent in one of the SIT message formats listed in the column “Conflict Alert” in Table 10, above. B.5.8 Notification of Country of Registry A Notification of Country of Registry (NOCR) message is sent to the country where the beacon is registered (based on the country code in the beacon message), as described in section A.4.7.5 of this Handbook. In each such case, the NOCR message is sent in one of the SIT message formats listed in the column “NOCR” in Table , above. B.5.9 Ship Security Alerting System Alert An alert from a Ship Security Alerting System (SSAS) beacon is processed as described in section A.4.7.1 of this Handbook. The SSAS alerts are formatted in the same SIT message formats as any other alert would be formatted in the same circumstances. B.5.10 Aircraft Distress Tracking Alert An alert from a Distress Tracking ELT(DT) beacon is processed as described in section A.4.7.3 of this Handbook. The ELT(DT) alerts are formatted in the same SIT message formats as any other alert would be formatted in the same circumstances. B.5.11 Return Link System Notification A notification of Return Link System (RLS) message is sent to the MCC that is responsible for liaison with the Space Segment Provider that operates the RLS satellite system, as described in section A.4.7.2 of this Handbook. That MCC then forwards the alert to the Return Link Service Provider (RLSP), who will issue the commands to the spacecraft as necessary to send the Type-1 Acknowledgement message on the satellite navigation signal to the beacon that initiated this alert. In each such case, the RLS notification message is sent in one of the SIT message formats listed in the column “RLS” in Table , above. B.5.12 Interferer Alerts The LEOSAR system can detect and locate strong interfering signals that are broadcast in the 406 MHz uplink frequency band. This is done by a processing that is very similar to the processing B-19 that was done to detect and locate the 121.5 MHz and 243.0 MHz beacons, before that processing was discontinued in 2009. The interferer alert message contains a number of message fields that are not relevant to any of the 406 MHz distress beacon alerts, as listed in Table and as described below. An interferer is reported in a SIT 121 message. It is identified by a value of “+4” for the Frequency Band (in MF \#12). B.5.12.1 Number of Sidebands A sideband is a band of frequencies, higher than or lower than the carrier frequency, that are the result of the modulation process. When the interferer processing discovers a sideband to a signal that it is processing, the frequency data is adjusted to match the frequency of the primary signal, and the data is combined with the primary data to improve the quality of the solution. The number of sidebands that are detected and processed is reported in MF \#19. B.5.12.2 Sweep Period and Standard Deviation The distress beacons that operate in the 121.5 MHz and 243.0 MHz frequency bands produce a signal that sweeps across the band; this signal was originally intended to produce a characteristic sound on an audio receiver, but it was used in the LEOLUTs to detect the signals from these beacons. The values that are reported for an interfering signal in MF \#20 are the default values. B.6 System Information The system data messages are listed in Table 4-4, with some indication of their contents. In addition to the message fields that are listed in Table 4-4, these messages also contain many of the control and identification message fields that are listed in Table of this Handbook. All of the message fields that are used in the SIT messages are specified in the SID (document C/S A.002), in Table B-1 (“Message Field Description”) and in Appendix B.1 to Annex B (“Message Field Definition”). B.6.1 Orbital Elements As explained in section 6.10, the orbital elements of a satellite are the data values that define the path of the satellite around the Earth. They can be presented in a number of different formats: • The Keplerian elements define the ellipse that is the path that the satellite follows around the Earth. • The Position and Velocity Vectors define the position and velocity of the satellite at a specified time. B-20 • The Two-Line Elements (TLEs) are a format developed by the North American Aerospace Defence Command (NORAD) to specify the elements in a format that is designed for use with the simplified perturbations models for the propagation of the orbit. Other formats are also available. At one time, Cospas-Sarsat used the Keplerian elements to exchange the LEOSAR orbit data; however, this was superseded by the use of the Position and Velocity Vectors. More recently, the TLEs have been the standard for use with the MEOSAR and GEOSAR systems. B.6.1.1 SIT 215 Message Format (Orbit Vectors) The SIT 215 message format is used to send a routine update of the orbit vectors for a LEOSAR satellite. The data in this message should be verified by the MCC. The MCC can decide whether or not the new elements should be forwarded to the associated LEOLUTs. For the Cospas-Sarsat System, the position and velocity vectors are specified in an Earth-fixed coordinate space; that is, a coordinate system that rotates with the Earth. The details of the Message Fields that are used to place these parameters in the messages are described in the SID. A sample of a SIT 215 message is available in Annex C of the SID. B.6.1.2 SIT 216 Message Format (Orbit Vectors) The SIT 216 message format is used to send a new set of orbit vectors after the completion of a LEOSAR satellite manoeuvre. The data in this message may be verified by the MCC. However, because the orbit after a manoeuvre is new, this data should always be forwarded to the associated LEOLUTs. If the data is not sent to a LEOLUT, there is a risk that future Doppler solutions from that LEOLUT will not be correct. For the Cospas-Sarsat System, the position and velocity vectors are specified in an Earth-fixed coordinate space; that is, a coordinate system that rotates with the Earth. The details of the Message Fields that are used to place these parameters in the messages are described in the SID. The format of the SIT 216 message is the same as that of a SIT 215 message, which is available in Annex C of the SID. The only difference is the value in the SIT number field (MF \#4). B.6.1.3 SIT 217 Message Format (Two-Line Elements) The SIT 217 message format is used to send a routine update of the TLE orbital elements for a MEOSAR satellite. The data in this message should be verified by the MCC. The MCC can decide whether or not the new elements should be forwarded to the associated MEOLUTs. The details of the Message Fields that are used to place the two lines in the messages, and the meanings of each of the fields on these two lines, are described in the entries for MF \#85 and MF \#86 in Appendix B.1 to Annex B (“Message Field Definition”) of the SID. A sample of a SIT 217 message is available in Annex C of the SID. B-21 B.6.2 LEOSAR SARP Calibration As explained in section 6.10.4, the calibration data for the Search and Rescue Processor (SARP) instrument that is carried on each of the Sarsat LEOSAR satellites is computed by the French MCC (FMCC) and distributed through the Cospas-Sarsat data distribution network to all MCCs. Table contains a list of the message fields that are used to transmit the SARP calibration data. Note that the calibration time (in MF \#37) is the time of the most recent rollover of the SARP time counter; that is, the last time the counter had a value of exactly 000000. Table B-11: SARP Calibration Data Message Fields This table lists the Message Fields that are used in the SARP Calibration Data messages. Message Field Number Name Calibration Time USO Frequency (for SARP-1 or SARP-2) 38a USO Frequency (for SARP-3) There are two different SIT message formats that are used to transmit the SARP calibration data: • The SIT 415 message format (for the SARP-1 and SARP-2 instruments), • The SIT 417 message format (for the SARP-3 instruments). Because the USO in the SARP-3 instrument operates at a different frequency than the earlier versions, the MF \#38a requires an extra digit to specify the USO frequency. Samples of a SIT 415 message and a SIT 417 message are available in Annex C of the SID. B.6.3 LEOSAR SARR Calibration As explained in section 6.10.5, Canadian MCC (CMCC) regularly transmits the current value of the SARR Calibration data, through the Cospas-Sarsat data distribution network, to all MCCs. Table contains a list of the message fields that are used to transmit the SARR calibration data. Table B-12: SARR Calibration Data Message Fields This table lists the Message Fields that are used in the SARR Calibration Data messages. B-22 Message Field Number Name SARR Frequency Calibration Offset SARR Frequency. Calibration Drift Time of SARR Frequency Calibration Determination The SARR calibration data is sent in a SIT 510 message; a sample of a SIT 510 message is available in Annex C of the SID. B.6.4 Satellite Command and Control Messages The satellite command and control messages are used to transmit the information required to maintain control of the spacecraft and to keep them working as planned. These are specialized messages that are used by the Space Segment Providers for the control of the SARP instruments on the spacecraft of the Cospas-Sarsat Space Segment. The SIT message formats that are listed in Table and Table are used for the control of the Search and Rescue Processor (SARP) instruments and the Search and Rescue Repeater (SARR) instruments on the LEOSAR satellites, respectively. Table B-13: SARP Control Message Formats These are specialized messages that are used by the Space Segment Providers for the control of the SARP instruments on the spacecraft of the Cospas-Sarsat Space Segment. SIT Name Description SARP Telemetry SARP telemetry data from a Sarsat spacecraft SARP Out of Limit Warning message to indicate abnormal performance of the SARP SARP Command Command request for the SARP instrument SARP Command Verification Verification of the execution (or non-execution) of a SARP command as requested by a command message Table B-14: SARR Control Message Formats These are specialized messages that are used by the Space Segment Providers for the control of the SARR instruments on the spacecraft of the Cospas-Sarsat Space Segment. SIT Name Description SARR Telemetry SARR telemetry data from a Sarsat spacecraft SARR Out of Limit Warning message to indicate abnormal performance of the SARR SARR Command Command request for the SARR instrument SARR Command Verification Verification of the execution (or non-execution) of a SARR command as requested by a command message These satellite command and control messages are not normally of interest to any other MCC. B-23 B.6.5 System Status A system status message is sent to carry information about a change in the status of some part of the System to all Ground Segment Providers. A system status message may provide information about: • The failure of: - A System element, - A System function. • The recovery of a System element or function after a failure. • Any reconfiguration of a System component. • A scheduled event or activity, such as: - System maintenance, - Integration of new System elements, - Testing of System elements. • The commissioning of: - New equipment, - New capabilities of existing equipment. In general, any information about the status of the Cospas-Sarsat System that may be of interest to all Participants may be distributed in a system status message. B.6.5.1 SIT 605 A system status message is sent in a SIT 605 format. The originating MCC sends the message to its associated nodal MCC, which sends it, in turn, to all the other nodal MCCs. Each nodal MCC than sends the message to all of the MCCs in its Data Distribution Region. In this way, all Cospas- Sarsat Ground Segment Providers receive the message. The information content of a SIT 605 message is contained in MF \#41, which is described in section B.7.1 below. A SIT 605 message may be generated by the automatic processing in an MCC computer, or it may be entered manually by an MCC operator. In either case, it will be distributed to all MCCs. The Cospas-Sarsat documents include a number of operational message templates, intended to provide a standard format for some common messages, including several system status messages. Some of these templates are discussed in section B.8 of this annex. B-24 B.7 Narrative Messages The data distribution system supports a number of narrative messages, which can be used to send a variety of different information messages to other Ground Segment Providers. The information content of many narrative messages is contained in MF \#41, which is described in section B.7.1 below. Unlike most SIT messages, the narrative messages are intended for the operator at the destination facility (MCC, LUT, RCC or other), and are not designed for automatic processing. The Cospas-Sarsat documents include a number of operational message templates, intended to provide a standard format for some common messages, including several narrative messages. Some of these templates are discussed in sections B.8 and B.9 of this annex. There are several variations of narrative message that are used in the data distribution system. All of them contain the standard control fields and many of them include the narrative text message field. These different message formats are explained in the sections that follow. Whatever the format, the narrative message will be sent, through the data distribution network, to the specified destination. B.7.1 Narrative Message Text The information content of a system status message and of many narrative messages is contained in MF \#41, which is a free-format sequence of narrative text. The text may be broken up into a sequence of individual lines, separated by an end-of-line sequence (carriage return, carriage return, line feed: “cr-cr-lf”). Any sequence of valid characters (see section B.1 of this Annex) may be inserted into a narrative message, except for the termination sequence described below. The information text in a narrative message is terminated by the termination sequence: • Two carriage returns, • One line feed, • Four “Q” letter characters, • Two carriage returns, • One line feed. In essence, this appears in the message as a new line that contains “QQQQ” and nothing else. B.7.2 SIT 915 (Simple Narrative Message) The SIT 915 message is a simple narrative message, which sends a block of free-format text to the destination. The text of a SIT 915 message is usually typed by the MCC operator. The information content of a SIT 915 narrative messages is contained in a narrative text message field, as described in section B.7.1 of this annex. B-25 B.7.3 SIT 925 (406 MHz Beacon Information with 15-Hex ID) The SIT 925 message is used to provide the registration information for a distress beacon, using the beacon identifier (15-character hexadecimal). The message contains the beacon identifier in MF \#22, followed by a free format narrative text field (see section B.7.1 of this annex). B.7.4 SIT 926 (406 MHz Beacon Information with 23-Hex ID) The SIT 926 message is used to provide the registration information for a distress beacon, using the beacon identifier (23-character hexadecimal). The message contains the beacon identifier in MF \#92, followed by a free format narrative text field (see section B.7.1 of this annex). B.7.5 SIT 927 (SGB Type Approval Information for MCCs) The SIT 927 message is used to distribute information about the operational characteristics of a second-generation beacon, as retrieved from the Type Approval Certificate (TAC) that was filed when the beacon was approved for use with the Cospas-Sarsat System. The SIT 927 message is generated by an MCC every time a new 406 MHz beacon design is type- approved. Like a SIT 605 message, the SIT 927 message is distributed to all MCCs. The intent of this message is to enable every MCC to build its own internal database that contains all of the necessary information about the beacons, so that they will be able to retrieve that information when it is required in an incident alert message in the future, without requiring access to the TAC database that is operated by the Cospas-Sarsat Secretariat. Table B-15: SGB Information from TAC These message fields are used to transmit the information from the Type-Approval Certificate database (built up from the contents of SIT 927 messages that are distributed as the beacons are type- approved). MF\# Name Description C/S Type Approval Certificate (TAC) Number information 1. First TAC number reported 2. Number of consecutive TACs reported 3. Total number of TACs in database Beacon Manufacturer Name SID Beacon Model Name SID Beacon Data Field Beacon characteristics (described and explained in the SID) B.7.6 SIT 985 (SGB Type Approval Information for SPOCs and RCCs) The SIT 985 message is used to distribute information about the operational characteristics of a second-generation beacon, as retrieved from the Type Approval Certificate (TAC) that was filed when the beacon was approved for use with the Cospas-Sarsat System. B-26 The SIT 985 message is used to provide this information to the distress authorities who will be dealing with an incident alert from the subject beacon. As an interim measure, it is also used to send this information to an MCC that is not qualified as an SGB-capable MCC. The SIT 985 message provides this information in the same message fields that are designated for use in a SIT 185 message (MF \#61b and MF \#61c). The data from this message can be taken and moved directly into the SIT 185 message to be sent to the distress authorities. B.8 Operational Message Templates As noted above and as listed in Table , the Cospas-Sarsat documents include a number of operational message templates, intended to provide not only a standard format for some common system status and narrative messages, but also to indicate the contents that would be appropriate in specific circumstances. Table B-16: Operational Message Templates This table contains a list of many of the templates that are provided in the Cospas-Sarsat documents for system status messages and narrative message that are commonly used in the System. Document Reference Section Figure Description C/S A.001 4.3 4-16 Beacon Test Co-ordination Message C/S A.001 5.2 5-1 Standard Message for Reporting Satellite Payload Status (See also sample messages in the SID: C/S A.002 Annex C) C/S A.001 5.2 5-2 Standard Message for Reporting Satellite Manoeuvres C/S A.001 5.2 5-3 Standard Message for Reporting Reactivation of the SARP Instrument C/S A.001 5.2 5-4 Standard Message for Reporting a Spacecraft Anomaly Some of these templates are discussed in the following parts of this section. Some additional sample messages are also presented and discussed in these following sections. In addition to the messages discussed here, Annex C of the SID (document C/S A.002) contains samples of many other different message formats. B.8.1 SIT 605 – MCC Backup Figure B.1 contains a sample announcement from a nodal MCC when it takes over as the backup for a non-nodal MCC in its Data Distribution Region (DDR). This message includes the information that the other MCCs in the DDR should be aware of: • The identification of the non-operational MCC (the Italian MCC – ITMCC), • The identification of the MCC that is providing the backup service (the French MCC – FMCC), • The times of the failure and the backup, B-27 • A request that all MCCs in the DDR acknowledge receipt of the message, • The contact information of the MCC that is providing the backup service, At any time when an MCC takes over as backup for another MCC, it should provide this information to all MCCs. FROM: FMCC TO: ALL MCCS SUBJECT: ITMCC BACKUP 1. ITMCC IS NOT OPERATIONAL FROM 0725 UTC DUE TO MAINTENANCE 2. THE FMCC HAS ASSUMED THE BACKUP AND DUTIES OF ITMCC AT 1200 UTC 3. MCCS ARE REQUESTED TO TRANSMIT ALL TRAFFIC FOR THE ITMCC TO FMCC 4. CENTRAL DDR MCCS ARE INVITED TO CONFIRM RECEIPT OF THIS MESSAGE BY SENDING AN ACKNOWLEDGE MESSAGE TO THE FMCC AFTER THE CONFIGURATION CHANGES ARE MADE 5. ITMCC WILL INFORM WHEN IT RESUMES THE NORMAL OPERATIONS. 6. FMCC COMMUNICATION ADDRESSES: AFTN LFIAZSZX FAX: +33 561 274 878 PHONE: +33 561 254 382 BEST REGARDS, FMCC Figure B.1: Sample SIT 605 Announcement of MCC Backup This sample message shows the announcement of an MCC assuming the backup of a not operational MCC that is not a nodal MCC. Note that this example is for the backup of an MCC in the Central DDR (CDDR). Because of a special arrangement in the CDDR, all MCCs within that DDR are configured to send alert messages to any other MCC in the same DDR; item 4 in the message includes a reminder that these MCCs will have to change their configuration to continue to support the network while the ITMCC is backed up by the FMCC. Figure B.2 and Figure B.3 contain announcements of the backup of a nodal MCC by another nodal MCC. B-28 FROM: AUMCC TO: ALL MCCS SUBJECT: AUMCC BACKUP OF USMCC 1. THE UMCC HAS REQUESTED THE AUMCC TO BACKUP THE USMCC AND UNDERTAKE THE ROLE OF THE NODAL MCC FOR THE WESTERN DDR. 2. THE AUMCC HAS BEEN RECONFIGURED TO ACCEPT USMCC ALERT DATA FROM WESTERN DDR MCCS AND NODAL MCCS AND HAS ASSUMED THE USMCC NODAL RESPONSIBILITIES. 3. WESTERN DDR MCCS AND NODAL MCCS ARE REQUESTED TO SEND A SIT 915 TO AUMCC WHEN THEY ARE RE-CONFIGURED TO SEND USMCC TRAFFIC TO AUMCC. 5. WESTERN DDR MCCS SHALL NOT TRANSMIT QMS DATA TO THE AUMCC DURING THE BACKUP. 6. AUMCC CONTACT NUMBERS ARE LISTED ON COSPAS-SARSAT WEB SITE. REGARDS AUMCC Figure B.2: Sample SIT 605 Announcement of MCC Backup This sample message shows the announcement of an MCC assuming the backup of a not operational nodal MCC. Although the formats are slightly different, both of these messages include the information that all other MCCs should be aware of: • The identification of the non-operational MCC, • The fact that it is a nodal MCC that is being backed up, • The identification of the MCC that is providing the backup service, • A request that all MCCs in the DDR of the failed nodal MCC acknowledge receipt of the message, • Information about how to contact the MCC that is providing the backup service. At any time when an MCC takes over as backup for another nodal MCC, it should provide this information to all MCCs. The message from the AUMCC in Figure B.2 also includes a reminder that, during the period while the backup is in effect, the MCCs in the DDR of the failed nodal MCC should not send the usual QMS data to the backup MCC. Since this is also stated in section 3.7.1 of the DDP, it is useful, but not essential information for this notification message. B-29 FM FMCC COSPAS-SARSAT TOULOUSE TO ALL MCCS DUE TO A TECHNICAL PROBLEM, FMCC ASSUMES THE BACKUP AND DUTIES OF THE CMC EASTERN DDR AND NODAL MCCS ARE REQUESTED TO TRANSMIT ALL TRAFFIC FOR THE CMC TO FMCC. FMCC SENDS DIRECTLY ALERT DATA WITHIN THE CMC SERVICE AREA TO APPROPRIATE SPOCS. WE REQUEST NODAL MCCS AND EASTERN DDRS MCC TO CONFIRM RECEIPT OF THIS MESSAGE BY SENDING A MESSAGE TO THE BACKUP FMCC AFTER CONFIGURATION CHANGES ARE MADE FMCC COMMUNICATION ADDRESSES: AFTN: LFIAZSZX FAX: +33 561 274 878 PHONE: +33 561 254 382 BEST REGARDS, FMCC OPERATIONS Figure B.3: Sample SIT 605 Announcement of MCC Backup This sample message shows the announcement of an MCC assuming the backup of a not operational nodal MCC. B.8.2 SIT 605 – MCC Resuming Operations after the Backup The messages in Figure B.4 and Figure B.5 are examples of the message that is sent from an MCC after it has returned to operation, to notify all MCCs when the backup is finished. FROM: ITMCC TO: ALL MCCS SUBJECT: ITMCC HAS RESUMED NORMAL OPERATIONS 1. THE ITMCC HAS RESUMED NORMAL OPERATION AT 2000 UTC, 15 JAN 2020. 2. CENTRAL DDR MCCS ARE REQUESTED TO RE-CONFIGURE THEIR MCC ACCORDINGLY. BEST REGARDS, ITMCC Figure B.4: Sample SIT 605 Announcement of MCC Resuming Operations This sample message shows the announcement of a non-nodal MCC resuming operations after it has been backed up. The message from the ITMCC in Figure B.4 notifies all MCCs that the backup that was notified in Figure B.1 has been completed, and that the ITMCC and FMCC have returned to normal operations. This message again includes a reminder to the CDDR MCCs that they will have to reconfigure their systems to restore their normal network configuration. B-30 FROM: AUMCC TO: ALL MCCS SUBJECT: AUMCC RESTORED TO NORMAL OPERATIONS 1. THE AUMCC HAS RESUMED NORMAL SOUTH WEST PACIFIC DDR MCC NODAL RESPONSIBILITIES AT 2000 UTC, 15 JAN 2020. 2. NODAL MCCS, SOUTH WEST PACIFIC DDR MCCS SHOULD RESUME COMMUNICATIONS WITH THE AUMCC. 3. MCCS ARE REMINDED THAT MESSAGE NUMBER SEQUENCES MAY INITIALLY BE OUT OF SEQUENCE. 4. AUMCC THANKS USMCC FOR COOPERATION DURING THIS BACKUP TEST. REGARDS, AUMCC Figure B.5: Sample SIT 605 Announcement of MCC Resuming Operations This sample message shows the announcement of a nodal MCC resuming operations after it has been backed up. The message from the Australian MCC (AUMCC) in Figure B.5 is not related to the notifications of backup in the earlier sample messages; it is a statement that the AUMCC has returned to normal operations after it was backed up. (This backup would have been announced in a separate SIT 605 message, not included here.) This message also includes two reminders for the receiving MCCs: • MCCs in the South West Pacific Data Distribution Region (SWPDDR), for which the AUMCC is the nodal MCC, should return to their normal operations. • The sequence of message numbers will have been interrupted by the backup and will return to normal after the backup is concluded. As a result, MCCs may expect to detect message sequence errors on the next message received from the AUMCC. These reminders are not essential, but they may be useful to the receiving MCCs. B.8.3 SIT 915 – Beacon Test Coordination Figure 4-16 (“Beacon Test Co-ordination Message”) in section 4.3 (“Procedures for the Co- Ordination of Beacon Tests”) of the DDP (document C/S A.001) includes a template for a SIT 915 message to announce the plans for a test of a Cospas-Sarsat 406 MHz beacon. This template includes the headers and titles to identify the expected content of each line of the message. The intent of this message is to provide other MCCs with all of the information that they may need to understand the plans for this test, and to inform them of where they can go to get more information about this test. Figure B.7 is an example of a message, based on the template in Figure 4-16 of C/S A.001, that could be sent to notify other MCCs about plans for a beacon test. It shows the kind of information that should be included in this notification message to ensure that the other MCCs are aware of the test and that they will be able to deal with the data that it produces. B-31 FROM: ITMCC TO: DESIGNATED MCCS SUBJECT: 406 MHZ BEACON TEST A. TEST OBJECTIVE: FUNCTIONAL ELT BEACON TEST B. TEST DESCRIPTION: NIL C. LOCATION OF TEST: LAT 45 42 N LONG 008 41 E - VERGIATE, ITALY D. DATE,TIME AND DURATION OF TEST: 13 SEP 2019 FROM 0730 UTC TO 0830 UTC E. BEACON 15 HEX ID CODE: 1EE87AA22A8FFBFF F. SPECIAL DATA COLLECTION AND PROCESSING REQUIREMENTS: NONE G. POINT OF CONTACT NAME: OPERATOR ITMCC LOCATION: ITMCC OPERATION ROOM TELEPHONE NO: +39 080 5344033-53441571 AFTN NO: LIJCYFYX FACSIMILE NO: +39 080 5342145 BEST REGARDS, ITMCC Figure B.6: Sample SIT 915 Notification of a Planned Beacon Test This sample message shows a notification message that could be sent to notify other designated MCCs about a planned beacon test. B.8.4 SIT 915 – Cospas-Sarsat Alert Results After a distress alert has been sent out by an MCC, it is recommended that the MCC should determine the results of that alert. Although there is no requirement to distribute this information, it can be sent to other MCCs in a SIT 915 narrative message from the operator of the MCC that originally sent the alert to the SAR destination. This information can also be sent to the Cospas- Sarsat Secretariat, who collect information on the use of the Cospas-Sarsat System and publish it in the annual Review of Cospas-Sarsat Status and Operations, which is reviewed at the annual meeting of the Cospas-Sarsat Joint Committee and which is also sent to ICAO and IMO. The illustrations in this section show some examples of such alert result messages. B-32 FM ITMCC TO CDDR MCCS ITMCC REF NO 17085 HEXACODE: ADCDEA59F24020D REF 406 BEACON: A967C9/0, COUNTRY:366 USA INFORMATION RECEIVED FROM IT-MRCC ROME RESULT: FALSE ALERT TYPE: B777 AIRCRAFT REG: N70GT OPERATOR: COMMERCIAL PLACE/POSITION: VERGIATE, ITALY (LILG) REASON OF BEACON ACTIVATION: BEACON MISHANDLING OTHER INFO: NIL BEST REGARDS, ITMCC Figure B.7: Sample SIT 915 Notification of a False Alert This sample message shows the notification that is sent after an alert is determined to have been a false alert. Figure B.7 is a message that can be sent to inform other MCCs when a false alert has been reported. It contains information about the beacon itself, as well as the reported reason for the activation of the beacon that resulted in the false alert. To assist MCC operators when identifying and reporting operational false alerts categorized under the seven categories in document C/S A.003, section “Operational False Alerts” and its Appendix A.1, Figure B.8 below provides an information graphic to visually depict operational false alerts. Figure B.8: Information Graphic on Sources of False Alerts ![Image 1 from page 205](/images/cospas-sarsat/G-series/G010/G010_page_205_img_1.png) B-33 Figure B.9 below is a message that can be sent to inform other MCCs about a real distress incident that has been reported. It contains information about the beacon itself, as well as information about the results of the Search and Rescue operation triggered by this alert. (Because of the size of the message, the figure has been divided into two parts in this Handbook.) FM ITMCC TO CDDR MCCS REF 406 BEACON HEXACODE FROM MRCC ROME QUOTE A: VESSEL/CRAFT IDENTITY NAME: ISVFG TYPE: CESSNA 152 CALLSIGN: ISVFG FLAG: ITALY POSITION: 46 10.1 N 011 22.4 E - TRENTO, ITALY B: BEACON TYPE () EPIRB (X) ELT () ELT(DT) () PLB C: ALERT CLASSIFICATION (X) DISTRESS ALERT () FALSE ALARM () UNDETERMINED (INCLUDING STOPPED BEFORE LOCATED) D: CAUSE OF ACTIVATION (X) CRASH () BEACON MISHANDLING () BEACON MALFUNCTION () MOUNTING/AVIONICS INTERFACE FAILURE () ENVIRONMENTAL CONDITIONS () MAINTENANCE ACTIVATION () VOLUNTARY ACTIVATION () UNKNOWN E: PERSON INVOLVED NUMBER OF PERSON INVOLVED: 2 RESCUED: 2 INJURED: NIL SAFE: 2 DEAD: NIL MISSING: NIL F: TYPE OF ALERT () ONLY ALERT (X) FIRST ALERT () SUPPORTING DATA () DATA NOT USED IN SAR G: OTHER INFO: PLEASURE AIRCRAFT CESSNA 152 CRASHED 5KM SOUTHEAST OF TRENTO, ITALY DUE TO ENGINE FAILURE. TWO (2) POB WERE RESCUED SAFE AND WELL. UNQUOTE BEST REGARDS, ITMCC Figure B.9: Sample SIT 915 Notification of a Real Distress Incident This sample shows a narrative message that is distributed with information about a real distress incident that was reported by the Cospas-Sarsat System. B-34 There is no specific information that is required in this message; the intent is to provide useful information about the incident that resulted in the original alert, and the contribution of the Cospas- Sarsat System in resolving the matter. Of course, the successful rescue of the persons on board the aircraft is important to report. B.8.5 Filtering Doppler Position The procedures for the filtering of data are specified in sections 3.2.3.2 (“Filtering of Redundant Data”) and 3.2.10 (“Filtering Old Alert Data”) of document C/S A.001, “Cospas-Sarsat Data Distribution Plan”. The examples in this section show the results of QMS testing by a nodal MCC. The messages that are used are based on the templates that are contained in document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”, and are listed in Table of this Handbook. When an anomaly is detected, the nodal MCC sends a narrative message, using the format of one of the status warning messages from these templates as shown in Figure B.10, to the associated MCC to notify them of the anomaly and to request that they suppress any data that may be unreliable. At the same time, the associated MCC is expected to investigate and to correct any problem that may have caused this anomaly. /61939 00000/2270/20 139 1350 FTP /915/2470 /SYSTEM ANOMALY NOTIFICATION MESSAGE DATE: 1350 UTC, 18 MAY 2020 FROM: FMCC TO: ITMCC SUBJECT: LEOLUT LOCATION ACCURACY STATUS WARNING MESSAGE 1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE LEOLUT AND SATELLITE COMBINATION IS NOT MEETING THE REQUISITE LOCATION ACCURACY CRITERION AT 0000 UTC, 18 MAY 2020. LEOLUT 2471 AND SATELLITE 12 THE PERFORMANCE FOR THIS COMBINATION IS R.5: 75.0 PERCENT, R.10: 100.0 PERCENT. 2. REQUEST A CHECK FOR THE CAUSE OF REDUCED LOCATION ACCURACY. REGARDS QQQQ /LASSIT /ENDMSG Figure B.10: SIT 915 Location Accuracy Warning Message This sample message is the notification to the associated MCC that the location accuracy for a LEOLUT/LEOSAR combination is not compliant with the requirements in section 2.5.4.1 of C/S A.003. B-35 If the anomaly is not resolved and the 5-km accuracy ratio falls below 80%, a non-conformity status message is then distributed to all MCCs to inform them of the issue and of any data suppression that will result from it. The system status message, in Figure B.11, which shows the results of QMS testing by a nodal MCC, is an example of such a message. In this case, the FMCC has found that the Italian LEOLUT 2471 is not achieving the required location accuracy with data from satellite S12, and the location data from this LUT / satellite combination is now being suppressed. The SIT 605 message distributes this information to all MCCs. In this case, the filtering does not require the complete suppression of the incident alert data. As prescribed for the QMS processing, the alert data will continue to be distributed, but that distribution will be based only on the beacon detection and on the information content of the beacon message. Following the notification of the SIT 605, the associated MCC, in accordance with procedures in section 2.5.4.2 (b) (iii) of C/S A.003, sends a SIT 915 informing the nodal MCC that the alerts for this LEOLUT / LEOSAR combination are being suppressed. Figure B.13 contains a sample of such a message, sent from the ITMCC to the nodal FMCC informing that alert data from the combination of LEOLUT 2471 and satellite S12 is being suppressed. Continuing to follow the QMS requirements explained in section 4.6 of this Handbook, when the problem has been resolved, the nodal MCC will distribute a new SIT 605 message to notify all MCCs that the System solution accuracy of the LEOLUT/satellite combination has returned to normal. B-36 /61749 00000/2270/20 134 1350 FTP /605/2470 /SYSTEM ANOMALY NOTIFICATION MESSAGE DATE: 1350 UTC, 13 MAY 2020 FROM: FMCC TO: ALL MCCS SUBJECT: LEOLUT LOCATION ACCURACY NON CONFORMITY STATUS MESSAGE 1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING LEOLUT AND SATELLITE COMBINATION IS NOT MEETING THE REQUISITE LOCATION ACCURACY CRITERION AS AT 0000 UTC, 13 MAY 2020 LEOLUT 2471 AND SATELLITE 13 THE PERFORMANCE FOR THIS COMBINATION IS R.5: 50.0 PERCENT, R.20: 100.0 PERCENT. 2. THE CORRESPONDING CHANGES TO THE LOCATION ACCURACY AND AVAILABILITY STATUS HAVE BEEN MADE TO THE COSPAS-SARSAT WEBSITE AND DOPPLER SOLUTION DATA FOR THE LEOLUT AND SATELLITE COMBINATION IS BEING SUPPRESSED. REGARDS QQQQ /LASSIT /ENDMSG Figure B.11: Sample SIT 605 Announcement of LEOSAR Location Accuracy Problem This sample message is a notification that data for a described combination of LEOLUT and LEOSAR satellite will be suppressed due to the results of the QMS testing by the nodal MCC. (See section 2.5.4.2 of C/S A.003.) /09919 00000/2470/20 134 1418 /915/2270 /FM ITMCC TO FMCC SUBJECT: LEOLUT LOCATION ACCURACY NON CONFORMITY STATUS MESSAGE. IN ACCORDANCE WITH COSPAS SARSAT C/S A003 PARA 2.5.4.2 ITMCC HAS FILTERED DOPPLER SOLUTION DATA FOR COMBINATION LEOLUT 2471 AND SATELLITE S13. BEST REGARDS ITMCC QQQQ /LASSIT /ENDMSG Figure B.12: Sample SIT 915 Announcement of Doppler Location Filtering This sample message is a notification that data for a described combination of LEOLUT and LEOSAR satellite will be suppressed. (See section 2.5.4.2 of C/S A.003.) B-37 The next sample, in Figure B.13, states that the accuracy produced by the identified combination of the LEOLUT 2471 and the LEOSAR satellite S11 is now meeting the required standard, and that the distribution of the solution data from this LUT / satellite combination has returned to normal. /61232 00000/2270/20 137 1350 FTP /605/2470 /SYSTEM ANOMALY NOTIFICATION MESSAGE DATE: 1350 UTC, 16 MAY 2020 FROM: FMCC TO: ALL MCCS SUBJECT: LEOLUT LOCATION ACCURACY CONFORMITY STATUS MESSAGE 1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING LEOLUT AND SATELLITE COMBINATION LOCATION ACCURACY HAS RETURNED TO NORMAL AS AT 0000 UTC, 16 MAY 2020: LEOLUT 2471 AND SATELLITE 13 2. THE CORRESPONDING CHANGE HAS BEEN MADE TO THE COSPAS-SARSAT WEBSITE AND DOPPLER SOLUTION DATA FOR THE ABOVE LEOLUT AND SATELLITE COMBINATION IS NO LONGER BEING SUPPRESSED. REGARDS QQQQ /LASSIT /ENDMSG Figure B.13: Sample SIT 605 Announcement of LEOLUT/Satellite Conformity Status This sample message shows the announcement from an MCC that the Doppler location accuracy ratio for LEOLUT 2471 / Sarsat 11 combination has returned to the normal status. (See section 2.5.4.2(a)(i) of C/S A.003.) /09922 00000/2470/20 137 1418 FTP /915/2270 FM ITMCC TO FMCC SUBJECT: LEOLUT LOCATION ACCURACY CONFORMITY STATUS MESSAGE. IN ACCORDANCE WITH COSPAS SARSAT C/S A003 PARA 2.5.4.3 ITMCC HAS RESUMED THE DISTRIBUTION OF DOPPLER SOLUTION DATA FOR COMBINATION LEOLUT 2471 AND SATELLITE S13. BEST REGARDS ITMCC QQQQ /LASSIT /ENDMSG Figure B.14: Sample SIT 605 Announcement of the Resumed Distribution of Doppler Solutions This sample message is a notification that data distribution for the described combination of LEOLUT and LEOSAR satellite has been resumed. (See section 2.5.4.2(b)(ii) of C/S A.003.) B-38 B.9 QMS Related Messages The Cospas-Sarsat document C/S A.003 includes a number of templates for the messages that are used in support of the Cospas-Sarsat Quality Management System (QMS). These templates, which are listed in Table , are intended to provide not only a standard format for some common system status and narrative messages, but also to indicate the contents that would be appropriate in specific circumstances. Table B-17: QMS Message Templates This table contains a list of many of the templates that are provided in Annex D of document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”, for system status messages and narrative message that are commonly used in the System. Reference Section Description 1.1 LEOLUT Availability Status Warning Message 1.2 LEOLUT Availability Non-Conformity Status Message 1.3 LEOLUT Availability Conformity Status Message 2.1 GEOLUT Availability Status Warning Message 2.2 GEOLUT Availability Non-Conformity Status Message 2.3 GEOLUT Availability Conformity Status Message 3.1 LEOLUT Location Accuracy Status Warning Message 3.2 LEOLUT Location Accuracy Non-Conformity Status Message 3.3 LEOLUT Location Accuracy Conformity Status Message 4.1 MEOLUT Location Accuracy Non-Conformity Yellow Status Message 4.2 MEOLUT Location Accuracy Non-Conformity Red Status Message 4.3 MEOLUT Location Accuracy Conformity Status Message 4.4 MEOLUT Location Accuracy Non-Conformity Yellow Status (Change from Red Status) 5.1 MEOLUT Location Probability Non-Conformity Yellow Status Message 5.2 MEOLUT Location Probability Non-Conformity Red Status Message 5.3 MEOLUT Location Probability Conformity Status Message 5.4 MEOLUT Location Probability Non-Conformity Yellow Status (Change from Red Status) 6.1 MEOLUT Detection Probability Non-Conformity [Yellow or Red] Status Message 7.1 MEOLUT Local Antenna Availability Non-Conformity [Yellow or Red] Status Message 8.1 MEOLUT Timeliness Non-Conformity [Yellow or Red] Status Message B-39 Some of these templates are explained in section B.8.5 and in the following parts of this section. In addition to the messages discussed here, Annex C (“Message Content by SIT”) and Annex D (“Anomaly Notification Messages”) of the SID (document C/S A.002) contain samples of many other different message formats. If the data required to determine any of the parameters in the messages described below is not available, then the value is reported as “n/i” [no information]. B.9.1 LEOLUT/LEOSAT Availability Status As a part of the QMS, each nodal MCC monitors the availability of every combination of a LEOLUT and a LEOSAR satellite that includes a LEOLUT in its DDR. When the combination of an associated LEOLUT and LEOSAR satellite fails to meet the availability criteria specified in section 2.5.2 (“LEOLUT Availability Assessment, Status Reporting and Follow-Up Actions”) of C/S A.003, the nodal MCC in whose DDR the LUT is located: • Sets the availability status indicator for that LUT / satellite combination on the Cospas- Sarsat website to yellow, • Sends a SIT 915 message to warn the MCC with which the LUT is associated of this availability problem, • Continues to monitor the availability of this LUT / satellite combination. Section 1.1 (“SIT 915 Warning Message” [LEOLUT Availability]) of Annex D of the document C/S A.003 contains a template for the narrative message that is used to warn an MCC when the combination of an associated LEOLUT and a LEOSAR satellite has failed to meet the availability criteria. This warning message is sent to request that the receiving MCC check its LEOLUT to determine the cause of the reduced availability: • If the LEOLUT is found to have a problem, then the system should be modified as necessary to correct the problem. Once this has been done, the nodal MCC (and any other MCCs that may have been affected) should be notified. • If the investigation determines that there is no problem with the LUT, then the receiving MCC should notify the nodal MCC and the Space Segment provider that is responsible for the LEOSAR satellite involved, so that they can investigate and take action as appropriate. If the combination continues to fail to meet the criteria for a three-day period, then the nodal MCC: • Sets the availability status indicator for this LUT / satellite combination on the Cospas- Sarsat website to red. • Sends a SIT 605 message to notify all MCC of the non-conformance of the availability of this LEOLUT / satellite combination. B-40 • Continues to monitor the availability of that LUT / satellite combination. The status message template in section 1.2 (“SIT 605 Status Message (Advising non-conformity)” [LEOLUT Availability]) of Annex D of the document C/S A.003 is used to notify all MCCs when the combination of the LEOLUT and LEOSAR satellite that are identified in the message has failed to meet the availability criteria over a three-day period. This non-conformance message is sent to inform all MCCs of the problem. No action is required of the receiving MCCs; however, they should be aware that this situation may result in the LUT not being able to provide alert data in its nominal coverage area: • It may not be able to provide data to confirm an alert that has been detected and located by another LUT/satellite combination. • It may not produce solution data at the predicted next time of visibility for any beacon that has been detected and located. The receiving MCC may also wish to check the Cospas-Sarsat website to see if there is any other related problem with the LUT or satellite involved, and to see when the data produced by this LUT/satellite combination returns to the nominal availability. When the availability returns to the normal range and has passed the appropriate criteria, the nodal MCC: • Sets the availability status indicator for this LUT / satellite combination on the Cospas- Sarsat website to green. • Sends a SIT 605 message to notify all MCC of the return to conformance of the availability of this LEOLUT / satellite combination. The nodal MCC notifies the other MCCs of the return to conformance of the availability of the LEOLUT / Satellite combination in a SIT 605 message, following the template in section 1.3 (“SIT 605 Status Message (Advising return to normal operations)” [LEOLUT Availability]) of Annex D of the document C/S A.003. B.9.2 LEOLUT/LEOSAT Location Accuracy Status As a part of the QMS, each nodal MCC monitors the location accuracy of the Doppler solutions that are produced by every combination of a LEOLUT and a LEOSAR satellite that includes a LEOLUT in its DDR. When the combination of an associated LEOLUT and LEOSAR satellite fails to meet the location accuracy criteria specified in section 2.5.4 (“LEOLUT Location Accuracy Assessment, Status Reporting and Follow-Up Actions”) of C/S A.003, the nodal MCC in whose DDR the LUT is located: • Sets the location accuracy status indicator for this LUT / satellite combination on the Cospas-Sarsat website to yellow. B-41 • Sends a SIT 915 message to warn the MCC with which the LUT is associated of this location accuracy problem. • Continues to monitor the location accuracy of this LUT / satellite combination. Section 3.1 (“SIT 915 Warning Message” [LEOSAR Accuracy]) of Annex D of the document C/S A.003 contains a template for the narrative message that is used to warn an MCC when the combination of an associated LEOLUT and a LEOSAR satellite has failed to meet the location accuracy criteria. This warning message is sent to request that the receiving MCC check its LEOLUT to determine the cause of the reduced location accuracy: • If the LUT is found to have a problem, then the system should be modified as necessary to correct the problem. Once this has been done, the nodal MCC (and any other MCCs that may have been affected) should be notified. • If the investigation determines that there is no problem with the LUT, then the receiving MCC should notify the nodal MCC and the Space Segment provider that is responsible for the LEOSAR satellite involved, so that they can investigate further and take action as appropriate. If this LUT / satellite combination continues to fail to meet the criteria for a three-day period, then the nodal MCC: • Sets the location accuracy status indicator for this LUT / satellite combination on the Cospas-Sarsat website to red. • Sets the availability status indicator for this LUT / satellite combination on the Cospas- Sarsat website to red. • Sends a SIT 605 message to notify all MCC of the non-conformance of the location accuracy of this LUT / satellite combination. • Continues to process alert messages from this LUT / satellite combination following the usual procedures for continuing QMS processing. • Processes alert messages from this LUT / satellite combination for distribution to all other MCCs based only on the contents of the 406 MHz message from the beacon, and not on the independent location solution produced by the LUT. • Continues to monitor the location accuracy of this LUT / satellite combination. The status message template in section 3.2 (“SIT 605 Status Message (Advising non-conformity)” [LEOSAR Accuracy]) of Annex D of the document C/S A.003 is used to notify all MCCs when the combination of the LEOLUT and LEOSAR satellite that are identified in the message has failed to meet the location accuracy criteria over a three-day period. This non-conformance message is sent to inform all MCCs of the problem. Each receiving MCC then processes alert messages from this LEOLUT / satellite combination based only on the contents of the 406 MHz message from the beacon, and not on the independent location solution B-42 produced by the LUT. During this period, they should be aware that this situation may result in the LUT not being able to provide alert data in its nominal coverage area: • It may not be able to provide data to confirm an alert that has been detected and located by another LUT/satellite combination. • It may not produce solution data at the predicted next time of visibility for any beacon that has been detected and located. Each receiving MCC may also wish to check the Cospas-Sarsat website to see if there is any other related problem with the LUT or satellite involved, and to see when the independent location data produced by this LUT/satellite combination returns to the nominal accuracy. When the problem is resolved and the location accuracy returns to the normal range and has passed the appropriate criteria, the nodal MCC: • Sets the location accuracy status indicator for this LUT / satellite combination on the Cospas-Sarsat website to green. • Sets the availability status indicator for this LUT / satellite combination on the Cospas- Sarsat website to green. • Sends a SIT 605 message to notify all MCCs of the return to conformance of the location accuracy of this LUT / satellite combination. The nodal MCC notifies the other MCCs of the return to conformance of the location accuracy of this LEOLUT / Satellite combination in a SIT 605 message, following the template in section 3.3 (“SIT 605 Status Message (Advising return to normal operations)” [ LEOSAR Accuracy]”) of Annex D of the document C/S A.003. At this time, all MCCs can return to the normal processing of alerts from this LUT / satellite combination. B.9.3 GEOLUT/GEOSAT Low Availability As a part of the QMS, each nodal MCC monitors the availability of every combination of a GEOLUT and GEOSAR satellite that includes a GEOLUT in its DDR. When the combination of an associated GEOLUT and GEOSAR satellite fails to meet the availability criteria specified in section 2.5.3 (“GEOLUT Availability Assessment, Status Reporting and Follow-Up Actions”) of C/S A.003, the nodal MCC in whose DDR the LUT is located: • Sets the availability status indicator for that LUT / satellite combination on the Cospas- Sarsat website to yellow. • Sends a SIT 915 message to warn the MCC with which the LUT is associated of this availability problem. • Continues to monitor the availability of this LUT / satellite combination. B-43 Section 2.1 (“SIT 915 Warning Message” [GEOSAR Availability]) of Annex D of the document C/S A.003 contains a template for the narrative message that is used to warn an MCC when the combination of an associated GEOLUT and GEOSAR satellite has failed to meet the availability criteria. This warning message is sent to request that the receiving MCC check its GEOLUT to determine the cause of the reduced availability: • If the GEOLUT is found to have a problem, then the system should be modified as necessary to correct the problem. Once this has been done, the nodal MCC (and any other MCCs that may have been affected) should be notified. • If the investigation determines that there is no problem with the LUT, then the receiving MCC should notify the nodal MCC and the Space Segment provider that is responsible for the GEOSAR satellite involved, so that they can investigate and take action as appropriate. If the combination continues to fail to meet the criteria for a three-day period, then the nodal MCC: • Sets the availability status indicator for this LUT / satellite combination on the Cospas- Sarsat website to red. • Sends a SIT 605 message to notify all MCC of the non-conformance of the availability of this GEOLUT / satellite combination. • Continues to monitor the availability of that LUT / satellite combination. The status message template in Section 2.2 (“SIT 605 Status Message (Advising non-conformity)” [GEOSAR Availability]) of Annex D of the document C/S A.003 is used to notify all MCCs when the combination of the GEOLUT and GEOSAR satellite that are identified in the message has failed to meet the availability criteria over a three-day period. This non-conformance message is sent to inform all MCCs of the problem. No action is required of the receiving MCCs; however, they should be aware that this situation may result in the LUT not being able to provide alert data in its nominal coverage area: • It may not be able to provide data to confirm an alert that has been detected and located by another LUT/satellite combination. • It may not produce solution data at the predicted next time of visibility for any beacon that has been detected and located. The receiving MCC may also wish to check the Cospas-Sarsat website to see if there is any other related problem with the LUT or satellite involved, and to see when the data produced by this LUT/satellite combination returns to the nominal availability. When the availability returns to the normal range and has passed the appropriate criteria, the nodal MCC: • Sets the availability status indicator for this LUT / satellite combination on the Cospas- Sarsat website to green. B-44 • Sends a SIT 605 message to notify all MCC of the return to conformance of the availability of this GEOLUT / satellite combination. The nodal MCC notifies the other MCCs of the return to conformance of the availability of the GEOLUT / Satellite combination in a SIT 605 message, following the template in section 2.3 (“SIT 605 Status Message (Advising return to normal operations)” [GEOSAR Availability]) of Annex D of the document C/S A.003. B.9.4 MEOLUT Location Accuracy Status Messages As a part of the QMS, each nodal MCC monitors the location accuracy of the Difference of Arrival (DOA) solutions that are produced by every MEOLUT in its DDR for all of its designated reference beacons. As long as it has at least 20 independent locations from any MEOLUT for all the designated reference beacons, the nodal MCC in whose DDR the MEOLUT is located updates the MEOLUT status on the Cospas-Sarsat website, following the location accuracy criteria specified in section 2.5.5.2 (“MEOLUT Location Accuracy”) of C/S A.003. Whenever the status changes, the nodal MCC sends a SIT 915 message to notify the MCC with which the LUT is associated of this location accuracy change. It then continues to monitor the location accuracy of this LUT. When the status changes from green to yellow, a warning message is sent to the MCC associated with the MEOLUT. Section 4.1 (“SIT 915 Message (Status changed from Green+ or Green to Yellow)” [MEOLUT Location Accuracy]) of Annex D of the document C/S A.003 contains a template for the narrative message that is used to warn an MCC when an associated MEOLUT is failing to meet the location accuracy criteria. This warning message is sent to request that the receiving MCC checks its MEOLUT to determine the cause of the reduced location accuracy: • The receiving MCC should process all alert messages from this MEOLUT and send them to the nodal MCC, following the usual procedures, for continuing QMS processing. • If the LUT is found to have a problem, then the system should be modified as necessary to correct the problem. Once this has been done, the nodal MCC (and any other MCCs that may have been affected) should be notified. • If the investigation determines that there is no problem with the LUT, then the receiving MCC should notify the nodal MCC, so that they can investigate further and take action as appropriate. Until the problem is resolved, the MCC processing of all alerts from this MEOLUT is based only on the contents of the 406 MHz beacon message and does not use the independent location from the MEOLUT. B-45 When this MEOLUT fails to meet the location accuracy criteria and its status is changed to red, then the nodal MCC: • Continues to process alert messages from this MEOLUT following the usual procedures for continuing QMS processing. • Processes alert messages from this MEOLUT for distribution to all other MCCs based only on the contents of the 406 MHz message from the beacon, and not on the independent location solution produced by the LUT. • Continues to monitor the location accuracy of this MEOLUT. When the location accuracy status of the MEOLUT changes to red, the status message template in Section 4.2 (“SIT 605 Status Message (Status changed to Red)” [MEOLUT Location Accuracy]) of Annex D of the document C/S A.003 is used to notify all MCCs that the MEOLUT identified in the message has failed to meet the location accuracy criteria. This non-conformance message is sent to inform all MCCs of the problem. Each receiving MCC then processes alert messages from this MEOLUT based only on the contents of the 406 MHz message from the beacon, and not on the independent location solution produced by the LUT. During this period, they should be aware that this situation may result in the LUT not being able to provide alert data in its nominal coverage area: • It may not be able to provide data to confirm an alert that has been detected and located by another LUT. • It may not produce solution data at the predicted next time of visibility for any beacon that has been detected and located. Each receiving MCC may also wish to check the Cospas-Sarsat website to see if there is any other related problem with the MEOLUT, and to see when the independent location data produced by this MEOLUT returns to the nominal accuracy. When the problem is resolved and the location accuracy returns to the normal range and has passed the appropriate criteria, the nodal MCC changes the location accuracy status to green and sends a SIT 605 message (following the template in section 4.3 (“SIT 605 Status Message (Status change from Red to Green+ or Green)” [MEOLUT Location Accuracy]) of Annex D of the document C/S A.003) to notify all MCCs of the return to conformance of the location accuracy of this MEOLUT. At this time, all MCCs can return to the normal processing of alerts from this MEOLUT. When the location accuracy status moves from red (failed) to yellow (not meeting the specification, but within a reasonable range), the nodal MCC changes the location accuracy status and sends a SIT 605 message (following the template in section 4.4 (“SIT 605 Message (Status changed from Red to Yellow)” [MEOLUT Location Accuracy]) of Annex D of the document C/S A.003) to notify all MCCs of this change of the location accuracy status of this MEOLUT. At this time, all MCCs can return to the normal processing of alerts from this MEOLUT. However, the associated MCC is asked to continue to investigate the status of its MEOLUT, and other MCCs should use caution when sending alerts from this MEOLUT to a SAR destination. B-46 B.9.5 MEOLUT Detection Probability Status Messages As a part of the QMS, each nodal MCC monitors the detection probability of the Difference of Arrival (DOA) solutions that are produced by every MEOLUT in its DDR for all of its designated reference beacons. As long as it has at least 20 independent locations from any MEOLUT for all the designated reference beacons, the nodal MCC in whose DDR the MEOLUT is located updates the MEOLUT status on the Cospas-Sarsat website, following the detection probability criteria specified in section 2.5.5.4 (“MEOLUT Detection Probability”) of C/S A.003. Whenever the detection probability status changes to yellow or red, the nodal MCC sends a SIT 915 message to notify the MCC with which the LUT is associated of this detection probability change. Section 6.1 of Annex D of the document C/S A.003 contains a template for the narrative message that is used to warn an MCC when an associated MEOLUT is failing to meet the detection probability criteria. This warning message is sent to request that the receiving MCC check its MEOLUT to determine the cause of the reduced detection probability: • If the LUT is found to have a problem, then the system should be modified as necessary to correct the problem. Once this has been done, the nodal MCC (and any other MCCs that may have been affected) should be notified. • If the investigation determines that there is no problem with the LUT, then the receiving MCC should notify the nodal MCC, so that they can investigate further and take action as appropriate. While the problem is being investigated, the receiving MCC should continue to process all alert messages from this MEOLUT and distribute them to other MCCs, following the usual procedures defined in the DDP. The nodal MCC will also continue to process all alert messages from this MEOLUT and distribute them to other MCCs, following the usual procedures defined in the DDP. B.9.6 MEOLUT Location Probability Status Messages As a part of the QMS, each nodal MCC monitors the location probability of the Difference of Arrival (DOA) solutions that are produced by every MEOLUT in its DDR for all of its designated reference beacons. As long as it has at least 20 independent locations from any MEOLUT for all the designated reference beacons, the nodal MCC in whose DDR the MEOLUT is located updates the MEOLUT status on the Cospas-Sarsat website, following the location probability criteria specified in section 2.5.5.3 (“MEOLUT Location Probability”) of C/S A.003. Whenever the location probability status changes, the nodal MCC sends a SIT 915 message to notify the MCC with which the LUT is associated of this location probability change. It then continues to monitor the location probability of this LUT. When the location probability status changes from green to yellow, a warning message is sent to the MCC associated with the MEOLUT. Section 5.1 of Annex D of the document C/S A.003 B-47 contains a template for the narrative message that is used to warn an MCC when an associated MEOLUT is failing to meet the location probability criteria. This warning message is sent to request that the receiving MCC check its MEOLUT to determine the cause of the reduced location probability: • If the LUT is found to have a problem, then the system should be modified as necessary to correct the problem. Once this has been done, the nodal MCC (and any other MCCs that may have been affected) should be notified. • If the investigation determines that there is no problem with the LUT, then the receiving MCC should notify the nodal MCC, so that they can investigate further and take action as appropriate. While the problem is being investigated, the receiving MCC should continue process all alert messages from this MEOLUT and distribute them to other MCCs, following the usual procedures defined in the DDP. When this MEOLUT fails to meet the location probability criteria and its status is changed to red, then the nodal MCC: • Continues to process alert messages from this MEOLUT, following the usual procedures from the DDP. • Continues to monitor the location probability of this MEOLUT. When the location probability status of the MEOLUT changes to red, the status message template in section 5.2 of Annex D of the document C/S A.003 is used to notify all MCCs that the MEOLUT identified in the message has failed to meet the location probability criteria. This non-conformance message is a SIT 605 message that is sent to inform all MCCs of the problem. The receiving MCCs then continue to process alert messages from this MEOLUT following the usual procedures defined in the DDP. During this period, they should be aware that this situation may result in the MEOLUT not being able to provide alert data in its nominal coverage area: • It may not be able to provide data to confirm an alert that has been detected and located by another LUT. • It may not produce solution data at the predicted next time of visibility for any beacon that has been detected and located. Each receiving MCC may also wish to check the Cospas-Sarsat website to see if there is any other related problem with the MEOLUT, and to see when the independent location data produced by this MEOLUT returns to the nominal location probability. When the problem is resolved and the location probability returns to the normal range and has passed the appropriate criteria, the nodal MCC changes the location accuracy status to green and sends a SIT 605 message (following the template in section 5.3 of Annex D of the document C/S B-48 A.003) to notify all MCCs of the return to conformance of the location probability of this MEOLUT. When the location probability status moves from red (failed) to yellow (not meeting the specification, but within a reasonable range), the nodal MCC changes the location probability status and sends a SIT 605 message (following the template in section 5.4 of Annex D of the document C/S A.003) to notify all MCCs of this change of the location probability status of this MEOLUT. The associated MCC is asked to continue to investigate the status of its MEOLUT. B.9.7 MEOLUT Local Antenna Availability Status Messages As a part of the QMS, each nodal MCC monitors the availability of the local antennas at every MEOLUT in its DDR. As long as it has at least 20 independent locations from any MEOLUT for all the designated reference beacons, the nodal MCC in whose DDR the MEOLUT is located updates the MEOLUT status on the Cospas-Sarsat website, following the local antenna availability criteria specified in section 2.5.5.5 (“MEOLUT Local Antenna Availability”) of C/S A.003. Whenever the local antenna availability status changes to yellow or red, the nodal MCC sends a SIT 915 message to notify the MCC with which the LUT is associated of this local antenna availability change. Section 6.1 of Annex D of the document C/S A.003 contains a template for the narrative message that is used to warn an MCC when an associated MEOLUT is failing to meet the local antenna availability criteria. This warning message is sent to request that the receiving MCC check its MEOLUT to determine the cause of the reduced local antenna availability: • If the LUT is found to have a problem, then the system should be modified as necessary to correct the problem. Once this has been done, the nodal MCC (and any other MCCs that may have been affected) should be notified. • If the investigation determines that there is no problem with the LUT, then the receiving MCC should notify the nodal MCC, so that they can investigate further and take action as appropriate. While the problem is being investigated, the receiving MCC should continue to process all alert messages from this MEOLUT and distribute them to other MCCs, following the usual procedures defined in the DDP. The nodal MCC will also continue to process all alert messages from this MEOLUT and distribute them to other MCCs, following the usual procedures defined in the DDP. B.9.8 MEOLUT Timeliness Status Messages As a part of the QMS, each nodal MCC monitors the timeliness ratio received by the MCC from all MEOLUTs, at every MEOLUT in its DDR. B-49 The timeliness ratio is defined in section 2.4.2.6 (“MEOSAR System Timeliness”) of C/S A.003 as the ratio of the number of solutions received from the MEOLUT within ten minutes to the total number of solutions received by the nodal MCC from all MEOLUTs. As long as it has at least 20 solutions from the MEOLUT, the nodal MCC in whose DDR the MEOLUT is located updates the MEOLUT status on the Cospas-Sarsat website, following the timeliness criteria specified in section 2.5.5.6 (“MEOLUT Timeliness”) of C/S A.003. Whenever the local antenna availability status changes to yellow or red, the nodal MCC sends a SIT 915 message to notify the MCC with which the LUT is associated of this local antenna availability change. Section 8.1 of Annex D of the document C/S A.003 contains a template for the narrative message that is used to warn an MCC when an associated MEOLUT is failing to meet the timeliness criteria. This warning message is sent to request that the receiving MCC check its MEOLUT to determine the cause of its poor timeliness performance: • If the LUT is found to have a problem, then the system should be modified as necessary to correct the problem. Once this has been done, the nodal MCC (and any other MCCs that may have been affected) should be notified. • If the investigation determines that there is no problem with the LUT, then the receiving MCC should notify the nodal MCC, so that they can investigate further and take action as appropriate. While the problem is being investigated, the receiving MCC should continue to process all alert messages from this MEOLUT and distribute them to other MCCs, following the usual procedures defined in the DDP. The nodal MCC will also continue to process all alert messages from this MEOLUT and distribute them to other MCCs, following the usual procedures defined in the DDP. - END OF ANNEX B - C-1 ANNEX C: LOCATION DATA CONCEPTS AND TERMINOLOGY There are many terms that are unique to the description of the various parts of the Cospas-Sarsat System. Some of these terms are defined or explained in the individual sections of this Annex. C.1 LEOSAR Doppler Solution Processing The LEOSAR solution processing is based on the Doppler effect, which changes the frequency of the received signal as the satellite passes over the beacon. C.1.1.1 Doppler Curve As the satellite approaches the beacon, the received frequency is increased by the Doppler effect. Then, as the satellite passes the beacon and moves away from it, the received frequency is decreased. When the received frequency is plotted over time, the result is a Doppler curve, as illustrated in Figure C.1. Figure C.1: A Sample Doppler Curve This illustration shows how the Doppler effect modifies the frequency of the signal that is received from a distress beacon at a LEOSAR satellite. The illustration also shows some of the key parameters that are used to define the Doppler curve and the independent position estimate that is generated by the LEOLUT solution processing: • The Time of Closest Approach (TCA, MF \#14) is the time when the satellite passes closest to the beacon. ![Image 1 from page 223](/images/cospas-sarsat/G-series/G010/G010_page_223_img_1.png) C-2 • The frequency bias (MF \#13) is the measure of the difference between the beacon frequency at the TCA and the nominal beacon frequency of 406.000 MHz. • The total Doppler shift (shown as “m” on right side of the diagram) is used in the solution processing to determine how close the satellite comes to the beacon. It is not included in any SIT message, but it determines the Cross-Track Angle (CTA, MF \#17). See section C.1.2 of this Annex. The Doppler curve that is determined by the set of time and frequency measurements collected by the LEOLUT on a particular pass of a satellite over a beacon is identified by an iterative curve-fit process. For each iteration, the TCA, CTA, and bias are adjusted until a good fit is achieved. The number of iterations (MF \#16) is the count of the number of adjustments that are required to identify the Doppler curve. During the curve fit process, there are some limitations on the adjustments that may be made at each step in the process. These are primarily the size of the adjustment: for each parameter, there is a minimum adjustment, and any smaller adjustment is not considered significant. However, there is an additional constraint on the CTA: to avoid an infinite sequence of jumps across the orbit plane when the CTA is close to 0°, no CTA below a threshold value (normally around 1°) is allowed. C.1.2 A and B Positions The CTA is the measure of the angle at the centre of the earth, between the satellite and the beacon, at the TCA. Since this angle could be on either side of the satellite orbit plane, the Doppler solution processing produces two position estimates, one on each side of the satellite orbit. These two positions are arbitrarily identified as: • The A-position, which is the position that is considered to be more probably the correct location, and • The B-position, which is the position that is considered to be less probably the correct location. The A- and B- positions are normally distinct; the only exception is when the satellite passes directly over the beacon, and the CTA is 0°. As noted above, the solution processing does not normally allow the positions to converge at this value. However, with a very small CTA, the two positions may be very close together. C.1.2.1 LEOSAR Ambiguity Resolution The existence of a solution with two different positions is an ambiguity that creates a requirement to identify which of these positions is the correct position of the beacon. This process of determining the correct position is called ambiguity resolution; it is addressed in section 4.3.4.4 and in section B.5.5 of this Handbook. The following paragraphs describe the ambiguity resolution process in the Cospas-Sarsat System. The first stage in the ambiguity resolution is performed in the LEOLUT. Because the Earth is not still, but is rotating below the satellite, it produces a small Doppler effect on the received signal. C-3 This effect is too small to show in a Doppler plane diagram (as shown in Figure C.1). However, if the LEOLUT has enough data, and if that data is sufficiently accurate, the LEOLUT can use this information to produce a probability (MF \#28): an estimate of the probability that the A-position is the true location of the beacon. The probability estimate generated by a LEOLUT is normally in a range of about 80% or higher. While this is a useful value, it is necessary to find further information to decide which of the two positions is the correct location for the beacon. The next stage in the ambiguity resolution is done in the MCC. As the MCC receives more data about a beacon, it can compare the positions to identify the correct position in the initial estimate. This is a part of the processing of confirming a beacon solution. To positively resolve the ambiguity of a LEOSAR Doppler solution, the confirming solution must be an independent solution (that is, it must satisfy the conditions listed in section 4.3.4.4 of this Handbook) that contains a position estimate that matches, to within the appropriate match criterion as listed in section 4.2.2 (“Position Matching”) of the DDP, one of the Doppler position estimates. For an MCC to be able to use two solutions to resolve the position ambiguity the two position estimates must be independent, and they must be computed from satellites that are in different orbital planes. This second condition requires that both of the A- or B- locations must be significantly different from the corresponding location in the other solution. If both of the two pairs of positions are too close together, as illustrated in Figure C.2, then these two solutions cannot be used to resolve the Doppler solution ambiguity. Figure C.2: Unresolved Doppler Match Scenario This diagram (Figure 4.9, “Unresolved Doppler Match Scenario (20 km circles)”, from the DDP – C/S A.001) illustrates a situation where the LEOSAR solution ambiguity cannot be resolved by two locations from satellites that are in parallel orbit planes. The circles are 20 km in radius, consistent with the match criteria specified in C/S A.001. ![Image 1 from page 225](/images/cospas-sarsat/G-series/G010/G010_page_225_img_1.png) C-4 Although the usual method to resolve the ambiguity of a Doppler solution is to wait for an independent solution to confirm one position estimate and to reject the image position, as described above, an MCC (or an RCC) may be able to do so by other means, such as: • The contact person (from the beacon register) may be able to provide this information. • The nature of the beacon may provide a clue. (For example, an EPIRB carried on a large ship should not be found in an inland location.) • Overflying aircraft may be able to confirm reception of beacon signals from one of the positions. • Other reports (radio or telephone calls, for example) may provide information. The results of these methods of resolving the ambiguity are not normally reported through the data distribution network in a SIT message; they will more likely be relayed by the operator (in a narrative message or a voice communication) to the RCC. However, if the occasion arose, an MCC operator could manually generate a SIT message to report these results. C.1.3 Time of Closest Approach (TCA) As noted in section C.1.1.1 above and illustrated in Figure C.1, the Time of Closest Approach (TCA) is the time when the satellite passes closest to the beacon. This time is used to determine the position of the satellite when it passes closest to the beacon; from this, the LEOLUT can compute the point on the surface of the Earth that is directly below the satellite (the sub-satellite point), and use that to estimate the beacon position. C.1.4 Cross-Track Angle (CTA) As explained in section C.1.2 above, the Cross-Track Angle (CTA) is the measure of the angle at the centre of the earth, between the satellite and the beacon, at the TCA. This value is used to determine the distance from the sub-satellite point. With the known path and position of the satellite, this distance is used by the LEOLUT to compute the position of the beacon. C.1.5 Number of Points For each beacon message that is relayed through the LEOSAR satellite, the LEOLUT collects the data associated with that message: • The contents of the beacon message, • The measured frequency of reception of the signal at the LEOSAR spacecraft, • The time of reception of the signal at the LEOSAR spacecraft. Each such data set constitutes one point for the solution processing. Note that the data may be received through either the SARP or the SARR instrument carried on the spacecraft; regardless, each set of measurements is a single data point to be processed. C-5 The number of points that is reported in MF \#21 (as defined in the SID, document C/S A.002) is the final count of the points that are used in the computation of the beacon solution. This number of points may not be the same as the total number of points available for use in the solution computation. Some of these points may be rejected and not used; reasons for rejecting a data point include: • The frequency value may be out of the expected range. • The frequency value may be an outlier in the data set (see below). • The time value (for a SARR measurement) may be too far from the time when the measurement is received. • The time value (for a SARP measurement) may be out of the expected range. • The frequency value may be an outlier in the data set (see below). As the LEOLUT processes the time and frequency measurements, it determines how closely these measurements fit a theoretical Doppler curve. If any of the measurements fall too far away from the theoretical curve that best fits the data, then that set of measurements is discarded as an outlier. After any point has been discarded, the process is repeated without that point. After the processing has gone through enough iterations and has converged to a solution, the number of points that were used in the final iteration is the count that is reported in MF \#21. Partial Doppler Curves A partial Doppler Curve is simply a truncated section of a Doppler curve. A LEOLUT may receive the data from a partial Doppler curve for either of two reasons: • Because of the location of the beacon and the curvature of the Earth (or local obstructions around the LUT), the spacecraft may not be visible to the LUT for some part of the pass. • Because of the obstruction caused by local objects in the signal path from the beacon, the spacecraft may not receive the signals from the beacon for some part of the pass. In both cases, the LUT has only a partial Doppler curve to work with. C.1.6 Window Factor Ideally, during each satellite pass, the LEOLUT should have one data point for each transmission from the beacon. Unfortunately, this is often not possible. As noted in section 0 above, the LEOLUT may only receive the data associated with a partial Doppler curve. Alternately, it must be noted that a distress incident is not an ideal situation for a radio transmitter; the signal from the beacon may be weak and may not always be detected by the processing on the spacecraft or in the LEOLUT. Whatever the reason, the quality of the solution that is computed by the LEOLUT is limited by the available data. C-6 The Window Factor (WF, MF \#15) is one measure of the quality of the data that was available for the LEOSAR solution computation. If the data time span includes the point of inflection of the Doppler curve, the Window Factor is set to zero. Otherwise, the value of the Window Factor is calculated according to the duration of the data and the length of time between the centre point of the data (in time) and the point of inflection of the Doppler curve. In the extreme case, with very few points at the end of the Doppler curve, the value of the Window Factor will be nine. The data that is used in the calculation of the Window Factor is illustrated in the diagram in Figure C.3: • TCA is the time of closest approach of the satellite to the beacon, at the point of inflection of the calculated Doppler curve. • Centre is the centre point (halfway between the first and last point, in time) of the data. • The time Separation, which equals the absolute value of (TCA-Centre), indicates the separation of the data from the point of inflection. • The time Duration is the duration (in time, from the first to the last data point) of the data actually available for the Doppler processing. The Window Factor is then equal to the integer part of ( 2 · Separation / Duration ). The calculation of the Window Factor is based on the values of the parameters that are used to compute the theoretical Doppler curve that is used to fit the measured data. Figure C.3: Window Factor Calculation In general, a solution that has a Window Factor of zero (that is, the data available for the computation cover a span of time that includes the TCA) can be expected to produce a reasonably ![Image 1 from page 228](/images/cospas-sarsat/G-series/G010/G010_page_228_img_1.png) C-7 accurate solution. In contrast, if the data points are all on the same side of the TCA, the solution may be less accurate. The higher the Window Factor (that is, the further the data is, in time, from the TCA), the less reliable the solution is likely to be. C.1.7 Theoretical Number of Points for a Particular Satellite and CTA The number of transmissions that a beacon can produce during a LEOSAR satellite pass is determined by the altitude of the satellite orbit and the distance of the beacon from the satellite orbit plane. Depending on the relative positions of the beacon, the spacecraft, and the LEOLUT, the duration of the pass and the number of transmissions that might be received may vary over a fairly wide range: • The duration of the pass will be between zero minute and about eighteen minutes. • The total number of transmissions during the pass will be between zero and twenty. The LEOLUTs are generally configured to track the satellite that will provide the most data, and not to track any satellite that will not be visible for more than five minutes. To assist an MCC operator to understand what might be expected on a given LEOSAR satellite pass, the document C/S A.003 (System Monitoring and Reporting) contains a Table C.3 (“Number of Points Transmitted by a Distress Beacon”) in Annex C (“Performance Parameters for System Self-Monitoring”) that lists the expected duration of each pass and the number of points that will be transmitted during that period for a wide range of LEOSAR situations: • For the COSPAS satellites (at 1000 km altitude) and SARSAT satellites (at 850 km altitude) • For horizon elevations of both 0° and 5° For information, the table also lists the maximum elevation of the satellite during the pass. Thee are all nominal values, based on the computation of the orbit and of the various parameters reported. In operational conditions, the actual number of transmissions may be one or two more or less than the nominal value in the table. Because of the high altitude of the MEOSAR orbits and the large number of satellites, a MEOLUT can always expect to see several spacecraft at all times. For this reason, a similar table has not been prepared for the MEOSAR satellites. Because of the nature of the geosynchronous orbit, a GEOSAR satellite will always remain visible to the GEOLUT that is tracking it. The GEOLUT can expect to receive every transmission from a beacon that is within the view of the GEOSAR spacecraft. No table of visibility is required. C-8 C.1.8 Next Time of Visibility The time reported for next time of visibility in MF \#29 depends on the system that generated this alert message: • For the LEOSAR system, this field indicates the next time of Loss of Signal (LOS) when the position is expected to be visible in local mode to a LEOSAR satellite that will be tracked by this LEOLUT. If the information is not available, the default value is used. • For the MEOSAR system, the default value is provided. • For the GEOSAR system, this field indicates the next time of LOS when the position is expected to be visible to a LEOSAR satellite. If the information is not available, the default value is used. C.2 MEOSAR Difference of Arrival (DOA) Solution Processing The MEOSAR solution processing is based on the observed differences in the Time of Arrival (TOA) and the Frequency of Arrival (FOA) of the messages from the distress beacon at the spacecraft. Since the time and frequency are not measured by the SARR instrument on the MEOSAR satellites, they must be measured and computed in the MEOLUT: • The TOA is the time when the message is received at the spacecraft. The time is measured when the message is received at the MEOLUT. The TOA is then computed in the MEOLUT by determining, based on the known orbit of the satellite and the characteristics of the instrument on the spacecraft, the delay between the time of arrival at the satellite and the time of arrival at the LUT. For a message that is received from a remote antenna, this value (presented as a negative number) is the Time Offset: Message Field number 69 in the SID (document C/S A.002). That time offset is added to the time measured at the MEOLUT to get the TOA. • The FOA is the frequency of the signal that carries the message from the distress beacon, as it is received at the spacecraft. The FOA is then computed in the MEOLUT by determining, based on the known orbit of the satellite and the characteristics of the instrument on the spacecraft, the frequency change between its reception at the satellite and the measurement at the LUT. For a message that is received from a remote antenna, this is the Frequency Offset: Message Field number 70 in the SID (document C/S A.002). That frequency offset is added to the frequency measured at the MEOLUT to get the FOA. With the TOA and FOA data from several different MEOSAR satellites, the MEOLUT can compute the Difference of Arrival (DOA) position of the beacon. C.2.1 Multilateration Although the term trilateration has been used to describe the MEOSAR DOA solution processing, the processing actually uses a multilateration algorithm; trilateration is a simplified algorithm that uses angles to determine a location in a two-dimensional Cartesian space. C-9 Multilateration (more completely, pseudo range multilateration) is a navigation and surveillance technique based on measurement of the TOAs of energy waves (for the Cospas-Sarsat MEOSAR system, radio waves) having a known propagation speed. Because the speed of propagation is known, the difference in the arrival times of the signal can be directly converted into a difference in the distances from the transmitter to each of the receivers. With enough information, this information can then be used to compute the location of the transmitting beacon. C.2.2 Single Burst Solution The multilateration algorithm is capable of producing a beacon position estimate with the data from a single beacon burst: one message transmitted by the beacon. The difference between the arrival times of a beacon message at two different spacecraft at known locations is used to determine a two-sheeted hyperboloid curve on which the beacon is located. Data from a third spacecraft will generate a new hyperboloid. The intersection of these two hyperboloids with the surface of the Earth produces a position for the transmitting beacon. With data from a third spacecraft, the intersection with the Earth’s surface is not required, and a three- dimensional position (including altitude) can be computed. Of course, the accuracy of the solution that is produced by these computations is limited by the accuracy of the available data. However, if more spacecraft are available, the additional measurements of the time of arrival from each of the spacecraft can be used to improve the accuracy of the computed position estimate. C.2.3 Multi-Burst Solution Each Cospas-Sarsat distress beacon transmits several messages over a period of time: • A first-generation beacon (FGB) transmits one message every fifty seconds. This specification was designed to enable the beacons to be detected by the LEOSAR system, operating over a single satellite pass of fifteen minutes or less. • A second-generation beacon (SGB) follows a similar pattern, but the rate of transmission of messages varies over time. The intent of this variation is to enable the users of SGBs to benefit from the ability of the MEOSAR system to compute an independent DOA position estimate from a single burst: the beacon transmits many messages when it is first turned on, and then switches to a slower rate as time passes. Although each single-burst solution is computed independently, the MEOSAR system can also compute a multi-burst solution. This can be done either by performing the solution processing on a data set that includes measurements from more than one beacon message transmission, or by computing several single-burst solutions and then merging them into a combined multi-burst solution. The second version of this process is essentially very similar to the solution merge processing that is done in some MCCs. And it can be performed in the MEOLUT or in an MCC. The initial C-10 implementation of the MEOSAR system makes use of the merging of single-burst solutions, for a variety of reasons: • An MCC has more solution data (from multiple MEOLUTs) to work with than a single MEOLUT; as a result, the combination of multiple single-burst solutions might be expected to provide better results. • The software to merge individual solutions already exists in many MCCs, so the cost of implementing this approach is lower than developing new software to process data from multiple messages to generate one solution in a MEOLUT. C.2.4 MEOLUT Configuration To perform the Difference of Arrival (DOA) processing, a MEOLUT must receive and process data from several MEOSAR satellites (at least four satellites, and preferably six or more) at the same time. This can be achieved in a number of different ways: • The MEOLUT can be designed with multiple tracking antennas and point each antenna to track a different satellite. • The MEOLUT can be designed with a single phased array antenna, which can track multiple satellites simultaneously. Individual beams of this phased array antenna can then track separate satellites. • A network of MEOLUTs can share their antennas, so that all the MEOLUTs have access to the data from all the antennas. • The MEOLUT can be networked with other MEOLUTs, and this network of MEOLUTs can share the data that is collected by each individual MEOLUT. This can be done with several MEOLUTs that are operated by the same Ground Segment Provider, or it can be done by networking MEOLUTs that are operated by different Ground Segment Providers. Every one of these configurations is used by one or more of the Ground Segment Providers in the Cospas-Sarsat MEOSAR system. C.2.4.1 Networked Antennas The European Union (EU) operates three MEOLUTs, which are located in Maspalomas (Canary Islands, Spain), Spitsbergen (Norway), and Larnaca (Cyprus). There are four tracking antennas at each location, and each antenna is controlled by the local MEOLUT at the same site. The EU has a central processor that prepares a coordinated schedule for all of these MEOLUTs, to avoid duplication of effort and to ensure the maximum coverage of the entire European area of responsibility for Search and Rescue. All three of the EU MEOLUTs are capable of reading data that is collected through the receivers that are connected to all of the twelve available antennas. The result is that each European MEOLUT is, effectively, a twelve-antenna MEOLUT with its antennas spread around the desired coverage area. C-11 Because each of the MEOLUTs can independently receive data from all of the antennas, the complete configuration (consisting of one MEOLUT processor and twelve antennas and receivers) of each MEOLUT has been separately commissioned and accepted into the Cospas-Sarsat Ground Segment. C.2.5 MEOSAR Quality Assessment The MEOAR DOA processing produces three related quality indications with each solution: • MF \#78 Quality Factor, • MF \#84 Quality Indicator, • MF \#89 Expected Horizontal Error. These are each described in the SID. The Quality Factor is a three-digit number that indicates the quality of the solution. The algorithm for computing this quality factor is not defined by Cospas-Sarsat; it is left to the designer of the individual MEOLUT to determine how it should be computed. However, a higher number is required to indicate a better-quality solution. The Quality Indicator identifies some specific characteristics that may affect the quality of the solution: • Bit 0 (value = 1): single burst position confirmed, • Bit 1 (value = 2): single burst position not confirmed, • Bit 2 (value = 4): DOA position outside satellite footprint. Since each characteristic is indicated by a single bit, these characteristics can be combined in the Quality Indicator that is stored in MF \#84. The Expected Horizontal Error (EHE) is a more precise estimation of the accuracy of a DOA location. The EHE is explained in detail in section C.5.2 of this Handbook. C.2.6 Uncorroborated Alerts During the initial implementation of the MEOSAR system, the first MEOLUTs were observed to generate a large number of uncorroborated alerts. An uncorroborated MEOSAR alert is: • An unlocated MEOSAR alerts, • That is generated from a single beacon message transmission that was relayed through a single satellite channel, • That contains a beacon identifier that does not match any previous message received at the MEOLUT. C-12 These alerts appeared to be associated with the reception of distorted (and invalid) messages from a real beacon. Since the beacon messages were not valid and the independent location estimate was not available, these uncorroborated alerts were of little or no use to the SAR community. For this reason, document C/S A.001 (Data Distribution Plan) specifies (in section 4.2.1.4, “Uncorroborated MEOSAR Alerts”) that an MCC should suppress the distribution of such messages. This section of the DDP includes a description of a few exceptional circumstances when an uncorroborated MEOSAR alert should be distributed. C.3 Two-Line (Orbital) Elements (TLE) The Two-Line (Orbital) Elements (TLE) format was developed by the North American Aerospace Defense Command (NORAD) for the transmission of the orbital elements of objects that are in Earth orbit. The details of this format, and the meaning of each field in the two lines of text that it defines, are listed in the Tables under MF \#85 and 86 of Appendix B.1 To Annex B (“Message Field Definition”) in the SID (document C/S A.002). The TLE include the orbital data to sufficient precision that they can be used by the Cospas-Sarsat LUTs and MCCs for all types of satellites that are used in the System. However, they are primarily used for the transmission of MEOSAR satellite orbital data. C.4 Moving Beacons The Cospas-Sarsat System was originally designed for the detection of beacons that are involved in distress incidents. The expectation was that, in most cases, these beacons are in fixed locations, and will not move during the period when they are active. However, there are many situations when a distress beacon may move while it is active: • During a maritime distress incident, a beacon is activated at sea: - The beacon will frequently be tossed (sometimes violently) by the wave action of a storm. - The beacon may drift slowly with the currents and tides of the sea. • With the advent of the ICAO Global Aeronautical Distress and Safety System (GADSS), beacons may be activated while carried on aircraft travelling at relatively high speeds. The slow motion of beacons at sea was not enough to disturb the computation of the independent beacon location using the LEOSAR Doppler algorithms. However, the MEOSAR DOA processing, which uses more precise measurements and can produce more accurate results, is more sensitive to beacon motion. During the MEOSAR Demonstration and Evaluation (D&E) phase, it was found that the independent location data that was computed by the MEOLUTs for a moving beacon was not accurate enough to meet the specifications defined in C/S T.019, “Cospas-Sarsat MEOLUT Performance Specification and Design Guidelines”, which did not recognize the different C-13 circumstances of a moving beacon. Since then, the MEOLUT specifications have been updated to explicitly identify (in section 5.6, “Location Accuracy”) the requirements for the location of beacons under different conditions: • The accuracy requirements for nearly-static beacons (moving at less than 0.5 metres per second) are defined in sections 5.6.1 and 5.6.2. • The accuracy requirements for slow-moving beacons (moving at between 0.5 metres per second and 10.0 metres per second) are defined in sections 5.6.3 and 5.6.4. • The accuracy requirements for fast-moving beacons (moving at greater than 10.0 metres per second) are defined in sections 5.6.5 and 5.6.6. The final details of the requirements for moving beacons (including the distinctions between static, slow-moving, and fast-moving beacons) are still (in 2023) being defined, but they are expected to be close to, but not the same as, those for static beacons. C.5 Independent Location Accuracy Estimates With each independent location solution that is generated by a LUT, the LUT also produces a location accuracy estimate. The nature of this accuracy estimate depends on the source of the location data: • A LEOLUT computes error ellipses, which is an estimate of the accuracy of the positions in its Doppler solution. • A MEOLUT computes the Expected Horizontal Error (EHE), which is an estimate of the error that might exist in each single-burst solution that it calculates. Both types of LUT also summarize this accuracy data into a single value, called a confidence factor, which is reported to the MCC (and forwarded to the SPOCs and RCCs) as Message Field # 30. These location accuracy estimates are all defined in Appendix B.1 To Annex B (“Message Field Definition”) in the SID (document C/S A.002). C.5.1 LEOSAR Error Ellipse A LEOLUT quantifies the accuracy of its Doppler location values in an error ellipse; an ellipse centred on the computed beacon position that is expected to contain the true position of the beacon 50% of the time. This error ellipse is specified in MF # 27 as: • Angle The angle between the true north and the major axis of the ellipse, • Semi-major axis Half the length of the long axis of the ellipse, • Semi-minor axis Half the length of the short axis of the ellipse. The value of the error ellipse parameters is reported, but not verified, during the commissioning of a LEOLUT. C-14 The nature of the error of a Doppler solution is usually determined by the accuracy of the time and frequency measurements that are used to compute the solution: • An error in the measurement of the time of reception of the beacon message results in a position error that is parallel to the direction of the satellite orbit. • An error in the measurement of the frequency of reception of the beacon message results in a position error that is perpendicular to the direction of the satellite orbit. For each solution, the error ellipse is computed from the statistical variation of the measured data that is used to generate the position estimates. C.5.2 MEOSAR Expected Horizontal Error The accuracy of each MEOSAR single-burst solution is determined by a number of factors: • The configuration of the satellites that relayed the data from the beacon to the MEOLUT, • The number of spacecraft that are available to relay the beacon messages, • The statistical consistency of the data measurements. The MEOLUT uses these factors to compute the Expected Horizontal Error (EHE); an estimate of the error that might exist in each single-burst solution that it calculates. For each MEOSAR DOA (Difference of Arrival) location, RCCs and SPOCs are provided with the EHE value. This EHE value is the radius of the circle centred on the MEOSAR DOA location that should contain the true beacon location with a 95% probability. In other words, there is a 95% probability that the location error, which is defined as the distance between the MEOSAR DOA location and the actual beacon location, is lower than the EHE value. Figure C.4 illustrates the configuration for which the MEOSAR DOA location error is lower than the associated EHE value, with the corresponding confidence percentage. The EHE specification is further refined to ensure that EHE values associated with MEOSAR DOA location provide a confident reflection of the location error, and in particular that the EHE does not overestimate the location error in any significant way. In addition to the 95% confidence requirement, the EHE values associated with the MEOSAR DOA location provided to an RCC or a SPOC must be smaller than 2 times the associated EHE value 99% of the time. In other words, there may only be a maximum 1% probability that the MEOSAR DOA location error is greater than 2 times the EHE value. Figure C.5 and Figure C.6, below, illustrate these two limits on the range of the DOA location error. C-15 Figure C.4: MEOSAR DOA Location Error The basic definition of the Estimated Horizontal Error (EHE) is illustrated for the case when the actual error is smaller than the associated EHE value. Figure C.5: Range Limits for DOA Location Error This illustration shows the probabilities that the actual location error will be inside each of the minimum and maximum values defined by the Estimated Horizontal Error (EHE). ![Image 1 from page 237](/images/cospas-sarsat/G-series/G010/G010_page_237_img_1.png) ![Image 2 from page 237](/images/cospas-sarsat/G-series/G010/G010_page_237_img_2.png) C-16 Figure C.6: DOA Location Error This illustration shows, in three dimensions, the probability that the actual beacon location will be within the circles of radius EHE and 2\*EHE. The EHE is normally computed in the MEOLUT, using the available information about the satellite configuration (the Dilution of Precision, or DOP) and the statistics on the accuracy of the time and frequency measurements that have been used in the computation of the DOA locations. C.5.3 Confidence Factor (CF) For both types of independent locations, the LUT also produces a Confidence Factor (MF \#30). This Confidence Factor classifies the expected error in the position into a small number of categories, as listed in the entry for MF \#30 in Appendix B.1 To Annex B (“Message Field Definition”) in the SID (document C/S A.002). C.6 Large Location Errors and Possible Causes Although the Cospas-Sarsat LUTs are designed to produce the best quality results possible, and the location accuracy of the independent position estimates is generally very good and meets the requirements of the LEOLUT and MEOLUT specifications (document C/S T.002 and C/S T.019, respectively), there are occasionally cases where the LUT produces a solution with a large location error. For these purposes, a large location error is defined as a position estimate that is more than fifty kilometres from the true beacon location. During the commissioning of a LUT, the accuracy of every solution is verified, and any independent location estimate that is more than fifty kilometres from the (known) true beacon position requires an explanation in the commissioning report. ![Image 1 from page 238](/images/cospas-sarsat/G-series/G010/G010_page_238_img_1.png) C-17 Some of the reasons for large location errors in the positions reported by the Cospas-Sarsat System are described in the following paragraphs. C.6.1 Encoded Location Data The encoded location data in the beacon message is generated by the beacon, based on either: • A Global Navigation Satellite System (GNSS) in the beacon, • An external navigation system on the vessel that carries the beacon. The existing GNSS systems are well understood, and the potential causes of error in the results that these systems produce include: • The inability of the beacon to receive the navigation signals from enough GNSS satellites, usually caused by obstructions around the beacon after a distress incident, • The inability of the beacon to remain operational for enough time to collect data and compute a position. Despite these potential problems, the vast majority of GNSS locations are reliable and accurate. Since the nature of the external navigation system is not known, it is not possible to include any comments on the potential causes of errors in the data that such a system might produce. In addition to any errors that may be generated by the source of the data, the formatting of the Cospas-Sarsat SIT messages for the transmission of the incident alert data may also force errors in the encoded location data. For the first-generation beacons, the amount of space available in the beacon message is limited (as specified in C/S T.001). The encoded location data is generally divided into two sections: • A coarse location estimate is provided in the available bits in the first protected field of the message. • An offset to a finer (more accurate) location is provided in the second protected data field, in the extended message are of a long message. Because of the limitations of the data field sizes in these message formats, the precision of the data is restricted, as indicated in Table . C-18 Table C-1: FGB Encoded Location Precision This table indicates the precision of the encoded location data in the various beacon message formats; this is the maximum accuracy that can be shown in a FGB alert message. Protocol Precision (Minutes & seconds) Maximum Error (kilometres) User Location 2’ 0” 3.7 Standard Location (coarse) 7’ 30” 13.9 Standard Location (fine) 0’ 2” 0.06 National Location (coarse) 1’ 0” 1.9 National Location (fine) 0’ 2” 0.06 RLS (coarse) 15’ 0” 27.8 RLS (fine) 0’ 2” 0.06 For each of these protocols (except for the User Location Protocol), the coarse location is available if only the first protected field of the message is received successfully by the LUT. If both the first and second protected fields of the beacon message are received successfully, then the fine resolution is available. Since the accuracy of a GNSS navigation system (or most other navigation systems) is usually significantly better than the FGB protocols can hold, the accuracy of the encoded location is normally limited by the available space in the beacon message. However, when the GNSS system produces a position with a large error (for any of the reasons described above), that error will be transmitted to the MCC. Additional information: According to document C/S T.001 section “Internal Navigation Device Performance”, for FGBs coded with the Standard, National, or RLS Location protocols, the GNSS receiver accuracy must be below 500m. For suspected moving beacons, MCC operators should take into account that the beacon may have drifted between the time the GNSS position has first been encoded in the beacon message and the time a new GNSS position information is sent to the RCC or SPOC within a SIT 185 message including this GNSS position. Specifically, for FGBs other than ELT(DT)s in in-flight mode: 1. a maximum 52.5-second period (up to 120-second period for ELT(DT) in post-crash mode) may occur between the time the GNSS receiver processes the GNSS position and the time this position is encoded in the beacon burst and sent to the satellite; C-19 2. the refresh rate of the internal GNSS receivers is defined such as: a) new beacons type-approved after 2022 should update their GNSS location between 4 minutes 25 seconds and 15 minutes (i.e., the GNSS position provided in a new SIT 185 message can be up to 15-minute old), b) new beacons type-approved between 2014 and 2022 should update their GNSS location at least once every 30 minutes (i.e., the GNSS position provided in a new SIT 185 message can be up to 30-minute old), c) it is not specified for beacons type-approved before 2014 (i.e., the GNSS position provided in a new SIT 185 message can be more than 30-minute old). Consequently, RCCs and SPOCs may receive SIT 185 messages updating the beacon position information for which only the independent position (i.e., the DOA or the Doppler position) has been updated, and therefore, still containing GNSS position information that has been refreshed several minutes prior to the timestamp indicated in the SIT 185 message. For most beacons, the refresh rate of their internal GNSS receiver is available on the Cospas- Sarsat website at https://www.cospas-sarsat.int/en/beacons-pro/experts-beacon- information/approved-beacon-models-tacs?view=tac\_beacons, selecting the TAC number and searching for the field “Encoded Position Data Update Interval [or Fix]”. (See also sections “GNSS Positions”, “Source of GNSS Position Data” and “Summary Guidance for the Use of Position Data” of document C/S G.007.) C.6.2 Doppler Location Data The LEOSAR Doppler solution processing may produce a large location error in some of the following circumstances: • A small number (four or fewer) of data points available for the solution processing - See the description of MF \#21 in Appendix B.1 To Annex B (“Message Field Definition”) in the SID (document C/S A.002). - This may be due to a beacon that is far away from the LUT (for a local mode solution). - It may also be caused by obstructions around the beacon, that prevent the beacon message from reaching the satellite. • A low Cross-Track Angle (CTA) (less than two degrees) - See MF \#17 in Appendix B.1 To Annex B (“Message Field Definition”) in the SID (document C/S A.002), - A low CTA indicates that the satellite has passed directly over the beacon; in this situation, the effects of small errors in the measurements are magnified. • A high Cross-Track Angle (CTA) (greater than thirty degrees) - See MF \#17 in Appendix B.1 To Annex B (“Message Field Definition”) in the SID (document C/S A.002), C-20 - A high CTA indicates that the satellite is far away from the beacon; in this situation, it may have difficulty getting good frequency measurements. • A high Window Factor (WF) (greater than two) - See MF \#15 in Appendix B.1 To Annex B (“Message Field Definition”) in the SID (document C/S A.002), - If the data does not include measurements near or around the Time of Closest approach, then the effects of small errors in the measurements are magnified. If more than one of these circumstances applies to any given solution, the possibility of a large location error is significantly increased. C.6.3 DOA Location Data The MEOSAR DOA solution processing may produce a large location error in some of the following circumstances: • Data available from only a small number of satellites - If data measurements are not available from at least three satellites, the MEOLUT cannot compute a DOA solution. With data from only three or four satellites, the accuracy of the solution will be limited. - This may be caused by obstructions around the beacon, that prevent the beacon message from reaching some of the available satellites. - It may also occur when the beacon is far from the MEOLUT, so that very few satellites have visibility of both the beacon and the MEOLUT. • A high Dilution of Precision - Dilution of Precision (DOP) is a term that is used in satellite navigation to specify the error propagation as a mathematical effect of navigation satellite geometry on positional measurement precision. - The DOP is the ratio of the error in the computed location to the error in the data measurements that are used to compute the location. If the DOP is high, the expected error will be high. - There are a number of different ways to express the DOP: ▪ HDOP – horizontal dilution of precision, ▪ VDOP – vertical dilution of precision, ▪ PDOP – position (3D) dilution of precision, ▪ TDOP – time dilution of precision, ▪ GDOP – geometric dilution of precision. - The HDOP is used in the computation of the Expected Horizontal Error (EHE) of a MEOSAR DOA solution. C-21 - Factors that increase the DOP (indicting that a larger position error may be expected) include: ▪ A low number of satellites (four or fewer), ▪ Satellite alignment (in a line that is straight or almost straight). If more than one of these circumstances applies to any given solution, the possibility of a large location error is significantly increased. Because the DOP includes the effects of the number of satellites on the solution accuracy, it (in the form of the HDOP) is used to compute the EHE of the MEOSAR DOA position estimates. - END OF ANNEX C - D-1 ANNEX D: CONTINGENCY PROCEDURES D.1 Operational Backup As noted in sections 4.1.2 and 5.2.5 of this Handbook, each MCC is expected to have in place suitable arrangements for backup capability, to be put into effect whenever the MCC cannot satisfy these requirements. As explained in the following sections of this Annex, this backup may be provided by: • A separate MCC system that is maintained and operated by the administration of the Ground Segment Provider that operates this MCC, which can be put into service when the primary MCC is not operational, • An arrangement with a neighbouring MCC to provide the MCC services when this MCC is not operational. Each of these backup arrangements is discussed in one of the following sections of this Annex. The following sections of this Handbook then provide information about the special concerns that are associated with: • An MCC that is relying on its backup for a long period of time, • Backup arrangements within a Data Distribution Region (DDR), and • The backup of a nodal MCC. The MCC specifications (in sections 5.9, “Backup Timing”, and 5.10 , “Additional Timing Requirements”, of document C/S A.005) require that the switch-over between an MCC and its backup facility, whether it is operated by the same administration or it is a foreign MCC, shall be completed within thirty minutes of notification of the requirement for the backup. And the implementation of backup procedures should never allow the delivery of alert messages to be interrupted for more than one hour. When an MCC switches its operations to a backup facility, it must notify other participants in the Ground Segment of this change. The status message SIT 605, defined in the SID (document C/S A.002) and described in section A.7.5.1 of this Handbook, is used for this purpose. Whether or not a back-up facility available from the MCC administration, all MCCs prepare a plan to hand over responsibility for their Service Area to another MCC in the event that the equipment or services that are used at the operational MCC are not able to continue to provide the necessary level of service. A description of the backup plans for each MCC is contained in section 5.3 (“Description of Cospas-Sarsat MCCs”) of document C/S A.001, “Cospas-Sarsat Data Distribution Plan”. D-2 Regardless of the backup arrangement that is in place for an MCC, the Programme requires that the backup be tested on a regular basis. Unless the back-up arrangements have been called upon operationally, they must be tested at least once a year. The schedule and the results of the backup test are reported in the annual Report on System Status and Operations, which is submitted by each Cospas-Sarsat Participant, and which is reviewed at each meeting of the Cospas-Sarsat Joint Committee. D.1.1 Internal Back-up MCC Several Ground Segment Provider administrations have decided that they wish to provide a complete MCC service, including backup facilities, within the scope of their own contributions to the Cospas-Sarsat Ground Segment. These administrations have installed two complete MCC facilities; sometimes these facilities are at separate locations, to avoid the risk of a single event disabling both MCC facilities. When an administration provides a second MCC facility, it should verify that this backup facility is fully capable of providing all of the services of a Cospas-Sarsat MCC. In theory, this would require that the backup facility go through a complete separate MCC commissioning test. In practice, most administrations only formally commission their primary MCC facility, and then separately verify (following their own internal test and verification procedures) that the backup MCC facility is fully compatible with the primary MCC. Although there is no explicit acceptance of this procedure in the Cospas-Sarsat documents, this process has been used for the many backup MCCs that are currently available in the System. Implicitly, it has been found to be acceptable to the Cospas-Sarsat Programme. D.1.2 Backup Another MCC An MCC that does not have a backup facility operated by the same administration (and, in fact, all MCCs that do have their own backup facility) must make arrangements with a neighbouring MCC to provide the backup support that is required in the case of the failure of the MCC. The arrangements for the backup of an MCC by a foreign MCC should be documented in a written agreement between the administrations that operate the MCCs and should be recorded in the entries for both MCCs section 5.3 (“Description of Cospas-Sarsat MCCs”) of document C/S A.001, “Cospas-Sarsat Data Distribution Plan”. The backup plan must be tested annually, and the results of each backup test should be reported by both MCCs in their annual Report on System Status and Operations. D.1.3 Long Term Backup The intent of the backup arrangements described above is to provide continuity of service when an MCC is unable to perform its normal duties. However, if the failure of an MCC continues for an extended period of time, these backup procedures place an untenable stress on the MCC that is providing the backup, and some other form of relief is required. This is addressed in section 6.3.4 (“Determining the Status of Operational Ground Segment Equipment”) of document C/S A.003. D-3 If an MCC remains in a non-operational state (as would be the case if it required backup) for more than forty-five consecutive days, or if it does not maintain operational status for more than six months within a one-year (twelve-month) period, then the nodal MCC that is responsible for the Data Distribution Region (DDR) in which the non-operational MCC is located (the associated nodal MCC) declares that non-operational MCC is in a “commissioned, not operational” (CNO) state. The nodal MCC sends a SIT 605 message to notify all MCCs of this change of status. The procedures described in section 3.7.4 (“Long-term Backup and Restoration of Operations”) of the DDP (document C/S A.001) are followed to determine when an MCC is declared in CNO status. Within the first forty-five days, the associated nodal MCC is notified that the problem that required the backup is a long-term issue, and that associated nodal MCC begins to prepare a plan to re-assign the responsibilities of the CNO MCC. This plan must address changes to the data distribution system to: • Treat the country that operates the NCO MCC as a SPOC of the nodal MCC or of another MCC in the DDR, • Assign each SPOC of the NCO MCC to another MCC in the DDR. At this time, the nodal MCC notifies all other MCCs of the issue. This allows the other MCCs in the DDR to prepare to take over the work of the NCO MCC, as necessary. If the failure continues for another forty-five days (or a shorter period, as determined by the nodal MCC and agreed by the other MCCs in the DDR), the nodal MCC then coordinates the implementation of the plan that it has prepared. The nodal MCC sends out a SIT 605 message to notify all Ground Segment Providers of the new configuration. The Cospas-Sarsat Secretariat is also notified, and the status of the MCC is changed on the Cospas-Sarsat website and in the appropriate System documents. This configuration remains in effect until the NCO MCC is returned to Full Operational Capability (FOC), as confirmed by a partial or complete re-commissioning of that MCC. See section 2.5 (“Recommissioning of a Previously Commissioned MCC”) of document C/S A.006 “MCC Commissioning Standard” for the procedure for the re-commissioning a CNO MCC. At that time, the original configuration (or a new configuration agreed by the nodal MCC and any other affected MCC) takes effect, and the nodal MCC sends another SIT 605 message to notify all Ground Segment Providers of this new configuration. D.1.4 Backup in the Same DDR Aside from nodal MCCs, the backup for an MCC is almost always performed by another MCC in the same DDR. D-4 D.1.4.1 Nodal MCC Backup Some nodal MCCs operate dual MCC equipment systems, so that they have an internal backup available in the event of a failure of the primary MCC equipment: • The AUMCC (Australian MCC) is co-located with the RCC Australia in Canberra. They have a disaster recovery plan and if conditions are such that the primary site has to be abandoned then personnel will be transferred to an alternative site that is set up to support most of the RCC functions and some AUMCC functions. • The USMCC (United States of America MCC) is located in Suitland, Maryland. The USA has a complete alternate MCC equipment at Wallops Island in Virginia. This provides a fully operational set of MCC equipment and communications access at a geographically separate site. The MCC personnel can move from the primary site in Suitland to the backup site on Wallops Island within half an hour of the decision to switch to the backup site. In addition, every operator of a nodal MCC has a backup agreement with another administration to provide data distribution services in the event of a failure at their MCC. In order to assure that the backup can provide all of the same services as the original MCC, the backup for a nodal MCC is almost always another nodal MCC: • The USMCC backs up the AUMCC. • The FMCC backs up the CMC (Cospas Mission Control, in Russia). • The SPMCC backs up the FMCC. • The USMCC backs up the JAMCC. • The FMCC backs up the SPMCC. • The AUMCC backs up the USMCC nodal functions. Note that the USA has two separate backup agreements: • The AUMCC provides backup services for the nodal MCC capabilities of the USMCC. • The Canadian MCC (CMCC) provides backup support for the distribution of data to the USA RCCs and SPOCs. This ensures that all of the functions of the USMCC are supported, without overloading the AUMCC and without requiring the AUMCC to support a lot of long-distance communications links. D.1.4.2 Non-Nodal MCC Backup The national MCCs that are not nodal MCCs all have an agreement in place with another MCC to provide backup support in the event of a failure of their MCC system. Each of these backup arrangements is identified in the entry for the MCC in section 5.3 “Description of Cospas-Sarsat MCCs”) of the Data Distribution Plan (document C/S A.001) and they are all listed in Table . D-5 Table D-1: MCC Backup Agreements The backup agreements that are in place, as identified in the DDP, are all listed in this table. Ground Segment Operator MCC Internal Backup External Backup Comments UAE AEMCC SPMCC Nodal MCC for SCDDR Algeria ALMCC SPMCC Nodal MCC for SCDDR Argentina ARMCC CHMCC South Africa ASMCC AUMCC Nodal MCC for SWPDDR Australia AUMCC USMCC Nodal MCC Brazil BRMCC Yes USMCC Nodal MCC for WDDR Canada CMCC Belleville, Ontario USMCC Nodal MCC for the WDDR Chile CHMCC USMCC Nodal MCC for WDDR China (P.R. of) CNMCC HKMCC Russian Federation CMC FMCC Nodal MCC Cyprus CYMCC ITMCC France FMCC SPMCC Nodal MCC Greece GRMCC ITMCC Hong Kong (China) HKMCC Yes TAMCC Indonesia IDMCC SIMCC India INMCC CMC Nodal MCC for EDDR Italy ITMCC FMCC Nodal MCC for CDDR Japan JAMCC USMCC Nodal MCC South Korea KOMCC JAMCC Nodal MCC for NWPDDR Malaysia MYMCC [AUMCC] [Nodal MCC for SWPDDR] Nigeria NIMCC [SPMCC] CNO - SPOC of SPMCC Norway NMCC UKMCC Pakistan PAMCC CMC Nodal MCC for EDDR Peru PEMCC ARMCC Qatar QAMCC SPMCC Nodal MCC for SCDDR Saudi Arabia SAMCC SPMCC Nodal MCC for SCDDR Singapore SIMCC THMCC Spain SPMCC FMCC Nodal MCC ITDC (Chinese Taipei) TAMCC HKMCC Togo TGMCC [SPMCC] [Nodal MCC for SCDDR] Thailand THMCC SIMCC Türkiye TRMCC Yes ITMCC United Kingdom UKMCC Yes NMCC USA USMCC Wallops Island, Virginia AUMCC and CMCC AUMCC provides nodal backup CMCC provides local backup Vietnam VNMCC HKMCC HKMCC D-6 D.1.5 Summary of Actions for MCC Scheduled and Contingency/Operational Backup The following table summarizes actions that should be performed by involved MCCs (Responsible and Backup) before, during and after a backup period. Table D-2: MCC Backup Actions Summary of Actions Responsible MCC Backup MCC Scheduled Backup  Suggested 1 – 2 weeks in advance, notify the scheduled activities and request backup service from the backup MCC (by SIT 915 or email) to begin the necessary coordination.  Suggested 1 – 2 weeks in advance, and once the backup period has been agreed, notify SPOCs in its service area (if any) the scheduled outage.  Notify all MCCs in advance (SIT 605)  Repeat notification to all MCCs (SIT 605) and SPOCs 24 hours prior to the scheduled activity. _________________________________  At the agreed time, stop data distribution, at least to the nodal MCC and SPOCs.  If more time than previously requested is necessary, notify the backup MCC (by phone) of the backup period extension. _________________________________  Once the scheduled activities are completed, request end of backup BY PHONE.  Start data distribution.  Notify end of backup to all MCCs (SIT 605) and SPOCs.  Communications test on primary link is recommended if backup longer than 6 hours. _________________________________  Five minutes before the backup start time, confirm backup readiness BY PHONE.  At the start time, implement the backup configuration changes.  Notify SPOCs (if any) in the service area of the failed MCC (e.g., SIT 915). _________________________________  Remove the backup configuration after receiving phone call.  Notify end of backup to all MCCs (SIT 605). D-7 Summary of Actions Responsible MCC Backup MCC Contingency Backup  Notify the failure and request the backup less than 1 hour after the issue is observed.  If still running, stop data distribution, at least to nodal MCC and SPOCs. _________________________________  Once the failure has been fixed, request end of backup BY PHONE.  Start data distribution.  Notify end of backup to all MCCs (SIT 605) and SPOCS.  Communication test on primary link is recommended if backup longer than 6 hours.  Implement the backup configuration changes immediately.  Notify backup to all MCCs (SIT 605).  Notify SPOCs (if any) in the service area of the failed MCC (e.g., SIT 915). _________________________________  Remove the backup configuration after receiving phone call.  Notify end of backup to all MCCs (SIT 605). Other appropriate actions, different than those indicated in the table above, could be agreed bilaterally between the Responsible and Backup MCCs. D.2 LUT Data to Non-parent MCC There are some occasions when a LUT may have to send data to an MCC that is not operated by the same Ground Segment Provider as the LUT. For the case of New Zealand and Australia, where the Australian Maritime Safety Authority (AMSA) has agreed that the AUMCC will provide MCC services to the New Zealand RCC, including support of the New Zealand LUTs. This arrangement is made under a bilateral agreement between the governments of Australia and New Zealand. Most other cases that require a LUT to send data to an MCC that is not associated with the LUT (that is, not operated by the same Ground Segment Provider) are the result of backup arrangements. Again, a bilateral agreement between the LUT operator and the operator of the backup MCC is required to document the arrangement. For any such arrangement to work successfully, the following are required: • An operational LUT and MCC, • An operational communications link to connect them. A formal agreement between the operators of the LUT and the MCC, which defines: • The circumstances under which the LUT will deliver data to the foreign MCC, • The communications link between the LUT and the MCC, D-8 • The data that the MCC will provide to the LUT (such as orbit and calibration data), • The data that the MCC will distribute to the Cospas-Sarsat Ground Segment, • How the MCC will distribute the data to the Cospas-Sarsat Ground Segment, • How the MCC will deal with data for the SAR Region of Responsibility of the country that operates the LUT, • Contact information for all parties to the agreement. With these arrangements, the LUT and MCC should be able to operate in the same manner as a national LUT and MCC operated by one Ground Segment Provider. D.3 Use of Email for Transfer of SIT Messages Electronic mail (email or email) is listed in document C/S A.002, “Cospas-Sarsat Mission Control Centres Standard Interface Description” (the SID), as an optional mode of communications between an MCC and its destination facilities, to be used by agreement on a bilateral contingency basis. Guidance on the use of email in the Cospas-Sarsat data distribution network is provided in Annex I (“Protocol for The Transmission of Sit Messages Via Electronic Mail (Email)”), to the SID. In addition to the uses that are formally permitted (by bilateral agreement) between MCCs, email is also used regularly by MCCs for informal communications with other MCCs or with other correspondents. This usage is informal and is not regulated by Cospas-Sarsat. Email is frequently used by MCCs to request or to confirm backup support from other MCCs, when the normal means of communications may not be available. It may also be used in place of voice or facsimile communications with other MCCs or with RCCs and SPOCs. D.4 Re-routing Alert Data between MCCs Section 3.8 (“Re-routing of Messages”) of the MCC specification (document C/S A.005) allows that an MCC may provide an alternate path to re-route messages between two MCCs when the direct link between them fails. This section describes the requirements for the implementation of this capability. Essentially, this requires an agreement among all of the participants involved and is intended to ensure that the use of this re-routing capability has virtually no impact on any other part of the Cospas-Sarsat Ground Segment. D.5 Special Procedures for the Transitional Phase-only The Cospas-Sarsat System is constantly in flux, as new technologies become available and are incorporated into the System. To maintain such a large system, spread over more than forty different countries, requires careful management of the introduction of new features into the system. D-9 When the new features are relatively small, the impact is low and can be managed by some relatively straightforward coordination among the Participants. However, for larger changes that affect many different parts of the system, more extensive coordination is required. There are several major changes in progress as this Handbook is being prepared (in 2023), and each of them requires special consideration in the procedures that are specified for the Cospas- Sarsat Ground Segment: • The consolidation of the MEOSAR system, • The introduction of Second-Generation distress beacons, • The consolidation of the Return Link Service by the Galileo Global Navigation Satellite System (GNSS), • The implementation of the Global Aeronautical Distress and Safety System (GADSS) by ICAO. These changes have a strong impact on the specifications for the MCCs, as described in several places in this Handbook. Because of the magnitude of these changes, it is not realistic to expect that all MCCs will be able to make any one of these changes at the same time. They will have to be phased in, and during this phase-in period there will be some MCCs that have not changed and other MCCs that have been upgraded to support the new service. The Cospas-Sarsat System documents are being revised to incorporate all of the changes required by these enhancements. These specifications of the Cospas- Sarsat Ground Segment include provision for each of these phase-in periods. The majority of the provisions for the introduction of these new capabilities into the Cospas-Sarsat Ground segment are contained in document C/S A.001 (Data Distribution Plan) and C.S A.003, “Cospas-Sarsat System Monitoring and Reporting”. Document C/S A.002 (Standard Interface Description) already includes the existing message formats, and it has been upgraded to include the descriptions of all of the new messages, so there is negligible impact on that document. Document C/S A.005, “MCC Performance Specification and Design Guidelines”, has a few references to the MEOSAR system, but they generally address the generation of specific MEOSAR messages. If those requirements are not implemented, they will have little effect on the rest of the Ground Segment. And document C/S A.006 (MCC Commissioning Standard) is only used when a new MCC is being commissioned, so the changes will not affect any operational MCC until it is upgraded. The Cospas-Sarsat Council agreed (at the CSC-62/OPN meeting) to a list of specific upgrades that are required in each unit of Ground Segment Equipment (GSE) to met various levels of capability, and the times when these various requirements must be applied. (See Annex 17 of the Summary Record: CSC-62/OPN/SR/Annex 17.) The management of the implementation of these specific changes is addressed in the following sections. As new innovations are introduced into the Cospas-Sarsat System in the future, similar management procedures are expected to apply. D-10 D.5.1 Encapsulation Procedure In each of these cases, an MCC that has been upgraded and is capable of handling the new data formats and contents is required to support the capability to format the data into a SIT 185 message (the format that it would normally use to send the data to a SPOC) and to encapsulate the text of that message into a narrative message (SIT 915; see section B.7.1 of this Handbook). The narrative message is sent to the destination MCC. Depending on the next destination of the data: • If the data is to be forwarded to another MCC, the entire message can be forwarded. • If the data is to be forwarded to a SPOC or an RCC, the SIT 185 message can be extracted from the narrative message and sent on. To allow for continuing operation as each MCC is upgraded to support the new System capability, the determination of which capability each destination MCC can support is required to be configurable in the MCC that is building the message. This procedure requires a small upgrade to every MCC (whether it supports the new capability of the System) to process these messages, but those changes were deemed to be relatively minor and were deemed acceptable by the Council. D.5.2 Distribution of MEOSAR Alerts to LG MCCs The introduction of the MEOSAR system brings a whole new set of independent location solutions, with different data contents and characteristics, and requires a new set of SIT message formats (as listed in Table in this Handbook). Every MCC must be updated to support the preparation, transmission, reception, and processing of these new messages. This gives rise to two classes of MCCs: • An LG-MCC can support only the old LEOSAR and GEOSAR message formats. • An LGM-MCC can support both the old LEOSAR and GEOSAR message formats and the new MEOSAR message formats. The DDP describes the procedure for the interim period, while both types of MCCs are in use, in section 3.7.5 (“Distribution of MEOSAR Alerts to MCCs that Are Only LEOSAR/GEOSAR- Capable”). The procedure that is specified in this section is to encapsulate any alert message for MEOSAR data (which would otherwise require a format that cannot be processed by an FG-MCC) as a SIT 185 format in a SIT 915 narrative message (see section D.5.1 of this Handbook). The tables in section 5.1 (“SID Implementation Status”) of the DDP (document C/S A.001) provide information about the current implementation status of message transmission and reception capability of each MCC in the Cospas-Sarsat Ground Segment. D-11 D.5.3 Distribution of Second-Generation Beacon Alerts to FGB-Only MCCs The introduction of Second-Generation distress Beacons (SGBs) brings a whole new set of beacon messages, with different data contents and characteristics, and requires a new set of SIT message formats (as listed in Table , Table , and Table in this Handbook). Every MCC must be updated to support the preparation, transmission, reception, and processing of these new messages. This gives rise to two classes of MCCs: • An FGB-Only MCC can support only the old First-Generation Beacon message formats. • An SGB-MCC can support both the old First-Generation Beacon and the new Second- Generation Beacon message formats. The DDP describes the procedure for the interim period, while both types of MCCs are in use, in section 3.7.6 (“Distribution of Second-Generation-Beacon (SGB) Alerts to MCCs that Are Only First-Generation-Beacon (FGB)-Capable”). The procedure that is specified in this section is to encapsulate any alert message containing SGB data (which would otherwise require a format that cannot be processed by an FGB-Only MCC) as a SIT 185 format in a SIT 915 narrative message (see section D.5.1 of this Handbook). The tables in section 5.1 (“SID Implementation Status”) of the DDP (document C/S A.001) provide information about the current implementation status of message transmission and reception capability of each MCC in the Cospas-Sarsat Ground Segment. D.5.4 Distribution of FGB-ELT(DT) Alerts to Non-FGB-ELT(DT) MCCs As noted in section 2.2.1.1, the International Civil Aviation Organization (ICAO) has developed the Global Aviation Distress and Safety System (GADSS), and the Cospas-Sarsat Programme is developing the Distress Tracking ELT – the ELT(DT) – in support of that initiative. The introduction of the ELT(DT) requires the support of some new beacon messages, incident alert messages, and data distribution procedures. These are addressed in section A.4.7.3 of this Handbook. The processing of the ELT(DT) beacons requires some new SIT message formats (as identified in Table , and Table in ANNEX B of this Handbook). Every MCC must be updated to support the preparation, transmission, reception, and processing of alerts from these new beacons. At the current time, this MCC enhancement is only a concern for FGBs. SGBs will also support these beacons, but this support is included in the SGB enhancements discussed in section D.5.3 of this Handbook. This gives rise to two classes of MCCs: • An FGB-ELT(DT)-capable MCC can support First-Generation ELT(DT) Beacons. • A non-FGB-ELT(DT)-capable MCC cannot support First-Generation ELT(DT) Beacons. The DDP describes the procedure for the interim period, while both types of MCCs are in use, in section 3.7.8 (“Distribution of FGB-ELT(DT) Alerts to MCCs that Are Not FGB-ELT(DT)- Capable”). The procedure that is specified in this section is to encapsulate any alert message for an ELT(DT) beacon (which would otherwise require a format that cannot be processed by a non-FGB- D-12 ELT(DT)-capable MCC) as a SIT 185 format in a SIT 915 narrative message (see section D.5.1 of this Handbook). The tables in section 5.1 (“SID Implementation Status”) of the DDP (document C/S A.001) provide information about the current implementation status of message transmission and reception capability of each MCC in the Cospas-Sarsat Ground Segment. D.5.5 Distribution of Alerts for RLS-Capable FGBs to Non-FGB-RLS MCCs The introduction of the Return Link Service (RLS) for distress beacons (initially by Galileo but expected from other GNSS providers in the near future) requires the support of some new beacon messages, incident alert messages, and data distribution procedures. These are addressed by the procedures described in section A.4.7.2 of this Handbook and the new SIT message formats identified in Table , and Table of this Handbook. Every MCC must be updated to support the preparation, transmission, reception, and processing of alerts from these new beacons. At the current time, this MCC enhancement is more of concern for FGBs; SGBs will also support these beacons, but this support is included in the SGB enhancements discussed in section D.5.3 of this Handbook. In any case, this gives rise to two classes of MCCs: • An FGB-RLS-capable MCC can support First-Generation Beacons with RLS capability. • A non-FGB-RLS-capable MCC cannot support First-Generation Beacons with RLS capability. The DDP describes the procedure for the interim period, while both types of MCCs are in use, in section 3.7.7 (“Distribution of Alerts for RLS-Capable FGBs to MCCs that Are Not FGB-RLS- Capable”). The procedure that is specified in this section is to encapsulate any alert message for an RLS- capable FGB beacon (which would otherwise require a format that cannot be processed by a non- FGB-RLS-capable MCC) as a SIT 185 format in a SIT 915 narrative message (see section D.5.1 of this Handbook). The tables in section 5.1 (“SID Implementation Status”) of the DDP (document C/S A.001) provide information about the current implementation status of message transmission and reception capability of each MCC in the Cospas-Sarsat Ground Segment. D.5.6 Distribution of RLSP Notifications The introduction of the RLS has brought another complication to the MCC processing of beacon messages. As explained section A.4.7.2 of this Handbook, the destination MCC (that is, the MCC that sends the incident alert message to the responsible SAR authority) also sends the notification message to the MCC that supports the Return Link Service Provider for the RLS-capable GNSS. D-13 As above, this gives rise to two classes of MCCs: • An FGB-RLS-capable MCC can support First-Generation Beacons with RLS capability. • A non-FGB-RLS-capable MCC cannot support First-Generation Beacons with RLS capability. The DDP describes the procedure for the interim period, while both types of MCCs are in use, in section 3.7.9 (“Distribution of Notifications for RLS-Capable FGB Alerts to the RLSP on Behalf of MCCs that Are Not FGB-RLS-Capable”). The procedure that is specified in this section is that every FGB-RLS-capable MCC that receives an RLS alert with a confirmed position sends the notification message to the MCC that supports the RLSP. This will result in more redundant messages going to the RLSP, but it will reduce the chance that an RLS beacon activation will not have the Type-1 Acknowledgement sent to the beacon. The tables in section 5.1 (“SID Implementation Status”) of the DDP (document C/S A.001) provide information about the current implementation status of message transmission and reception capability of each MCC in the Cospas-Sarsat Ground Segment. D.5.7 Operational Distribution of Alert Data for SGBs and FGB ELT(DT)s The DDP describes the interim procedure for the period before SGBs and FGB ELT(DT)s are approved by Council for operational use. In both cases, the MCCs that are capable of processing the subject beacons must have the capability to filter the data from the subject beacons, and they must have this capability configured to filter (that is, suppress) data from the beacons from operational distribution. In effect, the data is not to be distributed until Council approves the subject beacons for operational use. - END OF ANNEX D - E-1 ANNEX E: SPECIALIZED REQUIREMENTS E.1 Nodal MCC As explained in section 4.3 of this Handbook, a nodal MCC is the focal point for Cospas-Sarsat activities in each Data Distribution Region (DDR). E.1.1 Requirements A nodal MCC is a fully operational Mission Control Centre, which performs all of the functions, identified in section 4.1 of this Handbook, that are required of every MCC in the Cospas-Sarsat data distribution system. E.1.2 Operations In addition to the services that it provides as an operational MCC, a nodal MCC has many other responsibilities. As the leader of the Cospas-Sarsat Ground Segment operations in the Data Distribution Region (DDR), it must be able to: • Support multiple simultaneous communications activities, • Maintain a complete GEOSORT, so that all incident alert data that it receives, regardless of the DDR to which it belongs, will be sent to the correct MCC or other alert destination, • Validate and forward all system data that it originates or that it receives from another MCC, • Route narrative information messages to the correct destination, • Receive and process the Cospas-Sarsat Quality Management System (QMS) data for all components of the Ground Segment that are within its DDR (as described in section 4.6 of this Handbook), • Coordinate all of the activities necessary to support the functioning of the Cospas-Sarsat System within its DDR, including: - The commissioning (or re-commissioning) of an MCC, - The backup plans for all MCCs, - The backup tests of all MCCs, - Other test activities as determined by the Cospas-Sarsat Council. • Make the decision to declare a component of the Cospas-Sarsat Ground Segment as Commissioned not Operational (CNO), as appropriate. The staff at the nodal MCC must, at all times, be capable of performing any activities that may be necessary to support these functions. E-2 Because of the key role of the nodal MCC, its back-up plan must include provision for the support of all operations, including the nodal functions, if it were to go out of service. E.2 Reference Beacon Provider As specified in various Cospas-Sarsat documents, and as explained in section A.4.7.4 of 0 of this Handbook, the Cospas-Sarsat System requires that various types of reference beacons be available to support the operations of the System. These beacons are operated by the Participants in the Programme; the Participant who provides a reference beacon accepts certain obligations to the Programme and to the other Participants. The functions that are required of a reference beacon provider include: • Supplying the beacon and any related equipment necessary for its operation, • Maintaining the beacon and keeping it in operation according to the declared schedule, • Identifying and designating an MCC as an operational point of contact for communications regarding this beacon, • Notifying all Participants that the beacon is available, and providing the necessary information about it: - The precise location data for the beacon, - The exact transmit frequency, - The exact schedule for the operation of the beacon, • Providing information about the beacon to the Cospas-Sarsat Secretariat, so that they can maintain the Detailed Beacon Types page on the Cospas-Sarsat professional website, • Notifying other Participants when the beacon is not functioning as planned. To find out more about the available reference beacons, go to the Cospas-Sarsat professional website and select the tab, then and the or tab. Because of the use of these reference beacons, the information that is provided must be very accurate: • Location data accurate to at least 0.01 seconds of latitude and longitude in the Bureau International de l'Heure (BIH) Geodetic Reference System (for example, referenced to the WGS84 standard ellipse. This allows an error of approximately 3 metres, depending on the latitude; an extra digit of accuracy is even better. • Frequency data should be to 1 Hz or better. • The schedule should specify the times of activation to within one second or better. For those beacons, such as the orbitography reference beacons, which are essential to the operation of the System, the beacon provider is required to provide the assurance that the beacon will be E-3 maintained and kept active at all times. For other reference beacons, it is sufficient that the beacon be operated to the specified parameters by the best effort of the beacon provider. E.3 Beacon Registry Every country that participates in the International Maritime Organization (IMO) or the International Civil Aviation Organization (ICAO) is required, by the terms of their participation in those organizations, to maintain a registry of all distress beacons that are identified with their country code in the beacon message. The Cospas-Sarsat MCC that serves the area that includes the country must have access to the national beacon database registry and must support requests for the registration data from any other MCC. This support includes the ability to respond to requests, from the responsible authorities, for information about any beacon with a country code in the MCC Service Area. As each request is received, the MCC must forward the request for information to the appropriate national beacon registry and must return the information retrieved to the requesting authority. Each national beacon registry is organized according to national requirements. In some countries, the registry is divided into several parts, operated by different agencies according to the needs of the national administration. For example, in some countries, the beacon registry for EPIRBs is a part of a larger marine database of shipping, while the beacon registry for ELTs is contained in an aviation database. In such a case, the registration of PLBs requires a separate database. For any country that does not maintain its own beacon registry (or does not have a place to register a particular type of distress beacon), the Cospas-Sarsat Programme maintains the International Beacon Registry Database (IBRD), which will manage the registration records for that country. Depending on the request of the country, the IBRD may include all beacons registered with that countries code, or it may only include of beacons of a specified type. Access to the IBRD is available, on request, to all Cospas-Sarsat MCCs and to all authorized SAR authorities. The IBRD is specified and described in the System documents that are listed in Table 2-7, in section 2.4.5 of this Handbook. E.4 Space Segment Provider The International Cospas-Sarsat Programme Agreement (the ICSPA, document C/S P.001) was originally written with the idea that the Space Segment would be provided by the Parties to the Agreement, and that any other nation that wised to contribute to the Space Segment would accede to the ICSPA and become a Party to the Agreement. However, there have since been several instances where a country or an organization has offered to become a Space Segment Provider without acceding to the ICSPA. The Council, acting under the provisions of Article 9(i) of the ICSPA (giving it the function of “taking decisions upon matters of joint relations with States non-Parties to this Agreement, as well as international organizations”), has entered into specific individual agreements with these countries and organizations to enable them to become Space Segment Providers in the Cospas- Sarsat System. E-4 The current Space Segment Providers are listed in Table 3-2. Table identifies the agreements that define the terms under which non-Party Participants provide the Space Segment components listed in Table 2-1. These agreements are available on the Cospas-Sarsat website (under Documents, select and then and ). Table E-1: Space Segment Providers and Contributors to the Space Segment Space Segment Providers and Contributors Document Number Component Satellite Space Segment Contribution Canada C/S P.001 Sarsat LEOSAR SARR instruments Canada C/S P.001 SAR/GPS MEOSAR SARR instruments EUMETSAT C/S P.008 METEOSAT GEOSAR Satellite platform and all SAR instruments European Commission C/S P.017 SAR/Galileo MEOSAR Satellite platform and all SAR instruments France C/S P.001 SARP instruments European Commission (Galileo Joint Undertaking1) C/S P.014 SAR/Galileo MEOSAR Satellite platform and all SAR instruments India C/S P.009 Insat GEOSAR Satellite platform and all SAR instruments Russian Federation2 C/S P.001 Cospas LEOSAR Satellite platform and all SAR instruments Russian Federation2 C/S P.001 Glonass MEOSAR Satellite platform and all SAR instruments Russian Federation2 C/S P.001 Electro-L GEOSAR Satellite platform and all SAR instruments Russian Federation2 C/S P.001 Louch GEOSAR Satellite platform and all SAR instruments USA C/S P.001 Sarsat LEOSAR Satellite platform USA C/S P.001 DASS MEOSAR Satellite platform and all SAR instruments USA C/S P.001 SAR/GPS MEOSAR Satellite platform E-5 Space Segment Providers and Contributors Document Number Component Satellite Space Segment Contribution USA C/S P.001 GOES GEOSAR Satellite platform and all SAR instruments Notes to Table : The Galileo Joint Undertaking has been replaced by the European GNSS Supervisory Authority, which has since become the European Global Navigation Satellite Systems Agency (the European GNSS Agency, or GSA) as the party to this agreement and as the SAR/Galileo Space Segment Provider. The Union of Soviet Socialist Republics (USSR) was a Party to the original ICSPA, and the ICSPA was signed by representatives of the USSR and ratified by the USSR. In 1992, after the breakup of the USSR, the Russian Federation agreed to take the palace of the USSR as a Party to the ICSPA and as the Space Segment Provider for the COSPAS, SAR/Glonass, Electro-L and Louch spacecraft. Any other Government or Organization that wishes to become a Space Segment Provider should approach the Cospas-Sarsat Council (through the Party representatives, listed in document C/S P.010, or through the Secretariat). E.5 Return Link Service Provider The Return Link Service (RLS) is a service that provides the user with the ability to send short messages through the navigation downlink signals of a Global Navigation Satellite System (GNSS) to an identified receiver. For the Cospas-Sarsat System, the intended function is to send an Acknowledgement message to a receiver in the distress beacon that initiated an incident alert message. This facility is introduced in section 4.4.2.4 of this Handbook and is further discussed and explained in section A.4.7.2 of this Handbook. At the present time (in 2023), the only GNSS that operates an RLS capability is the European Commission’s Galileo GNSS, which is used in the SAR/Galileo MEOSAR system. The Chinese Beidou GNSS and Russian Glonass GNSS are both planning to offer this service, but neither of those RLS services is available yet. The RLS system has been proposed for various uses in relation to the Cospas-Sarsat System: • Type 1 Acknowledgement Acknowledge that the beacon message has been detected by the Cospas-Sarsat System, • Type 2 Acknowledgement Acknowledge that the beacon message has been received by the RCC that will organize the Search and Rescue efforts, E-6 • Remote Beacon Activation Turn the beacon on to start transmitting its distress message, • Beacon Cancellation Have the beacon transmit the correct sequence of cancellation messages and then stop transmitting. The only RLS service that is currently supported by the Cospas-Sarsat System is the Type-1 Acknowledgement. E.5.1 SAR/Galileo RLS More information about the RLS is available in the SAR Galileo Enhanced Service Definition Document (SAR SDD), published by the European Commission (EC). That document is available on the European GNSS Service Centre website at https://www.gsc-europa.eu/electronic- library/programme-reference-documents\#Galileo%20pub: Select and then click on to download the document (in PDS format). - END OF ANNEX E - F-1 ANNEX F: MONITORING AND TEST ACTIVITIES F.1 Commissioning Support As a part of its role as the coordinator of all Cospas-Sarsat activities for the Ground Segment Provider that operates the MCC, an MCC must be prepared to support the commissioning and testing of the various components of the Cospas-Sarsat System, as they are established, operated, and maintained by the administration that operates the MCC. These commissioning and test activities are described in the following sections of this ANNEX F of this Handbook. F.1.1 MCC Commissioning The commissioning of an MCC is the responsibility of the Ground Segment Provider administration that will provide and operate the MCC. The details of the requirements for the commissioning of a Cospas-Sarsat MCC are described in the MCC documents: • C/S A.005: MCC Performance specification and Design Guidelines, • C/S A.006: MCC Commissioning Standard, And in the other operational documents: • C/S A.001: Cospas-Sarsat Data Distribution Plan, • C/S A.002: Cospas-Sarsat Standard Interface Description, • C/S A.003: Cospas-Sarsat System Monitoring and Reporting. As described in the commissioning standard, the MCC will have to coordinate the activities that are required in support of the commissioning, including such things as: • Identifying the host MCC (HMCC) that will support the commissioning of the new MCC under development (DMCC), • Determining the MCC Service Area that will be supported by the new MCC, • Meeting with the HMCC and preparing the DMCC Commissioning Test Plan, • Coordinating with the HMCC to: - Notify other Ground Segment Providers of the commissioning activities and schedule, - Notify other Cospas-Sarsat Participants of the test beacons that will be activated in support of the commissioning, • Performing all of the necessary pre-integration test activities, as agreed with the HMCC, F-2 • Setting its configuration to ensure that data from the DMCC will not be distributed to other MCCs except as agreed in the Commissioning Test Plan, • Collecting data, as necessary, in support of the DMCC Commissioning Report, • Preparing the draft DMCC Commissioning Report, and submitting it to the HMCC for completion, • Coordinating with the HMCC to determine when the new MCC is ready to be declared at Interim Operational Capability (IOC), • Setting its configuration to support the distribution of data during the MCC’s IOC phase, • Monitoring the operations of the MCC during the IOC phase of operations, • Coordinating with the HMCC to determine when the new MCC is ready to be declared at Full Operational Capability (FOC), • Notifying the other Ground Segment Providers when the MCC is declared at FOC. Once the new MCC is fully operational, the MCC accepts the responsibility to participate fully in the Cospas-Sarsat Ground Segment, as described in documents C/S A.005 (MCC Performance Specification and Design Guidelines) and C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”. When the equipment in a commissioned MCC is upgraded or replaced, the new equipment may have to be partially or completely re-commissioned, depending on the nature of the changes to the MCC. During that re-commissioning, the upgraded MCC will have to provide a similar level of support as it would when a new MCC is commissioned. At the same time, it will have to continue to perform all of the services that it provides as an operational MCC. In most cases, this will require the parallel operation of the original MCC equipment and the new equipment under test until the re-commissioning of the MCC has been successfully completed. As a participant in the annual meeting of the Cospas-Sarsat Joint Committee (JC), the MCC manager will be expected to coordinate preparation and presentation of the commissioning report for their own MCC. They will also be expected to coordinate the review of other MCC commissioning reports within the administration that they represent, and to present the results of that review at the JC meeting. F.1.2 LUT Commissioning The commissioning of a LUT is the responsibility of the Ground Segment Provider administration that will provide and operate the LUT. The details of the requirements for the commissioning of a Cospas-Sarsat LUT are described in the documents that are listed in Table . F-3 Table F-1: LUT Commissioning Documents Document Number Title T.005 LEOLUT Commissioning Standard T.010 GEOLUT Commissioning Standard T.020 MEOLUT Commissioning Standard The MCC that is operated by the same Ground Segment Provider, and which is associated with the new LUT, will be expected to coordinate the activities that are required in support of the commissioning, including such things as: • Notifying other Ground Segment Providers of the commissioning activities and schedule, • Notifying other Cospas-Sarsat Participants of the test beacons that will be activated in support of the commissioning, • Coordinating these activities with other MCCs, • Setting its configuration to ensure that data from the LUT under test will not be distributed to other MCCs until the LUT has passed the commissioning tests, • Providing data, as necessary, in support of the LUT Commissioning Report, • Reviewing the LUT Commissioning Report, • Confirming that the LUT has passed the commissioning tests and is ready to be declared at Interim Operational Capability (IOC), • Setting its configuration to support the distribution of data from the new LUT to the rest of the Cospas-Sarsat Ground Segment when the LUT achieves IOC and FOC, • Notifying the other Ground Segment Providers when the LUT is declared at IOC, • Monitoring the operations of the LUT during the IOC phase of operations, • coordinating the submission of the LUT Commissioning Report to the Cospas-Sarsat Secretariat for review by the Cospas-Sarsat Joint Committee (or alternate meeting, as determined by Council), • Confirming that the LUT has successfully operated during its IOC phase and is ready to be declared at Full Operational Capability (FOC), • Notifying the other Ground Segment Providers when the LUT is declared at FOC. Once the new LUT is fully operational, the MCC accepts the responsibility to monitor the operations of the LUT, as described in document C/S A.005 (MCC Performance Specification and Design Guidelines) and the document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”. When a commissioned LUT is upgraded or replaced, the new equipment may have to be re- commissioned, depending on the nature of the changes to the LUT. During that re-commissioning, F-4 the associated MCC will have to provide a similar level of support to the modified LUT as it would for a new LUT. As a participant in the annual meeting of the Cospas-Sarsat Joint Committee (JC), the MCC manager will be expected to coordinate preparation and presentation of the commissioning report for any LUT that is operated by their administration. They will also be expected to coordinate the review of other LUT commissioning reports within the administration that they represent, and to present the results of that review at the JC meeting. F.1.2.1 Notifying a LUT to ITU Although it is not a part of the commissioning of a LUT, the LUT commissioning standards all state that “Administrations should register their [LUT’s] use of the 1544.5 MHz frequency band by notifying their [LUTs] with the International Telecommunication Union (ITU) in accordance with article 11 of the radio regulations.” As a part of its role as coordinator of the national participation in the Cospas-Sarsat Programme, an MCC should be prepared to assist its administration with the registration of all associated LUTs. As indicated in section 2.2.1.3, each LUT commissioning standard includes an Annex H, with a copy of the form approved by ITU for this notification and a description of how the form should be filled out for the LUT. In addition, ITU offers, on its web site (at www.itu.int), a link to download software to generate a form to register an Earth Station and to fill it before sending it to ITU. The web site also has a document that explains how to use this software tool. The MCC should ensure that all associated LUTs are notified to ITU. One of the main purposes of the declaration of LUTs to ITU is to ensure that these LUTs could formally benefit from the “Protection criteria for the Cospas-Sarsat Users Terminals in the 1544-1545 MHz” (ITU-R M.1731). When a LUT is officially declared at ITU, any interference matter in the received frequency of the LUT could be brought to ITU and resolved in accordance with appropriate ITU procedures. When a LUT has not been declared to ITU this process cannot be used so easily. F.1.3 Space Segment Commissioning The Cospas-Sarsat Programme makes use of spacecraft that are contributed by the Parties and other Space Segment Providers. Because these spacecraft are generally designed for other purposes, and the Cospas-Sarsat payloads are carried as payloads of opportunity, Cospas-Sarsat is generally not in a position to specify the requirements for these payloads. Consequently, Cospas- Sarsat does not commission the spacecraft in the same sense as it does for the Ground Segment components. That is, the commissioning does not verify that the spacecraft meets a prescribed specification. Instead, the commissioning of the Space Segment consists in the measurement and reporting of the characteristics of each spacecraft after it has been launched and is operating in orbit. The requirements for the commissioning of a spacecraft are identified in the documents listed in Table F-2. F-5 Table F-2: Spacecraft Commissioning Documents Document Number Title T.003 Description of the 406-MHz Payloads Used in the Cospas-Sarsat LEOSAR System T.004 Cospas-Sarsat LEOSAR Space Segment Commissioning Standard T.011 Description of the 406 MHz Payloads Used in the Cospas-Sarsat GEOSAR System T.013 Cospas-Sarsat GEOSAR Space Segment Commissioning Standard T.016 Description of the 406 MHz Payloads Used in the Cospas-Sarsat MEOSAR System T.017 Cospas-Sarsat MEOSAR Space Segment Commissioning Standard In general, the commissioning of a spacecraft is performed by the Space Segment Provider that is responsible for that spacecraft. However, other MCCs may be called on to assist with the commissioning of a spacecraft: • If there is a need to activate one or more beacons in support of the commissioning tests, all MCCs will be notified, and may be asked to send the collected data (or the computed results) to the commissioning agency. • If the commissioning agency requires the support of a LUT other than the LUT(s) that it operates, it may ask another Ground Segment Provider for support of the commissioning. • Some MCCs may be asked to participate in the distribution of data from the spacecraft that is being commissioned. • Until the commissioning is completed, all MCCs may be asked to suppress the distribution of data from the spacecraft that is being commissioned. For most of these operations, the MCCs will usually be expected to perform only their normal operational functions. The MCC operator may also be expected to support the administration of the Space Segment Provider in the registration of the new spacecraft with ITU. As a participant in the annual meeting of the Cospas-Sarsat Joint Committee (JC), the MCC manager will be expected to coordinate the review of the spacecraft commissioning report within the administration that they represent, and to present the results of that review at the JC meeting. F.2 MCC Annual Backup Test The requirements for the testing of the backup arrangements for an MCC are described in sections 3.7.2 and 3.7.3 of the DDP (document C/S A.001). The backup arrangements for each MCC must be agreed in advance and must be recorded in section 5.3 of the DDP. F-6 Every MCC is required to test its backup procedures annually. This backup test should include tests of all of the functions listed (in section 5.3 of the DDP) as supported by the backup system. It should also include a test of each communications link that is used during the backup procedure. The annual backup test should be planned for a period of six hours or more; the actual time for the backup test should be agreed bilaterally between the MCC and its backup provider. The only time when this annual backup test is not required is when the backup procedure has been successfully exercised for a period of time not less than six hours during the year prior to the planned annual test. When an MCC plans a backup test, it is required to notify all MCCs, and all SPOCs that it will serve during this backup test, of the plans for this backup. (See section 3.6.4 of the DDP.) F.3 Monthly Communication Link Testing with SPOCs Each MCC is encouraged to perform a monthly communications test with every SAR Point of Contact (SPOC) within its Service Area, unless that communications link has been used successfully in operations during the previous month. The communications test consists of the transmission of a test message to the SPOC and the receipt at the MCC of an acknowledgement from the SPOC that the message has been successfully received at the SPOC. The acknowledgement must be a manual acknowledgement from the operator of the SPOC, received within thirty minutes of the original transmission; an automatic acknowledgement by the communications network is not sufficient for a successful test. The results of these communications tests are to be reported to the Cospas-Sarsat Secretariat. This information is summarized in the annual status report on system operations, which the Secretariat prepares and which is reviewed at the next meeting of the Cospas-Sarsat Joint Committee. This report is also shared with the IMO Sub-Committee on Navigation, Communications and Search and Rescue (NCSR) as a part of the annual report from the Cospas-Sarsat Secretariat. F.4 Beacon Type Approval Tests The use of Cospas-Sarsat distress beacons is regulated by each national administration. All administrations include a requirement that the design of any distress beacon that is sold and used operationally must be approved by the Cospas-Sarsat Council. The process for this approval is specified in document C/S T.007, “Cospas-Sarsat 406 MHz Distress Beacon Type Approval Standard”. The testing that is required by C/S T.001 includes, among other tests, a satellite qualitative test during which the beacon is activated and transmits its messages for an extended period of time. (This satellite qualitative test is described in section A.2.5 of the Type Approval Standard.) “This test is to be performed only in coordination with the cognizant Cospas-Sarsat Mission Control Centre (MCC) and local authorities.” That is, the MCC responsible for the Service Area in which the test is run must be notified of the test and must approve it. F-7 The MCC may also be asked to collect and to report on the data that is generated by the beacon during this test. While the MCC must consider the local Search and Rescue conditions at the time of the requested test, MCCs are encouraged to support these tests to the best of their ability. The results of the beacon type-approval tests are reported to the Cospas-Sarsat Council, and they are reviewed by an Experts Working Group convened by the Council before they are reviewed and approved by the Council. The type approval report for every beacon that is approved by Council is available on the Cospas-Sarsat website, under the tab: select and then select for the desired beacon model. F.5 Interference Monitoring In order to protect the Cospas-Sarsat System from being degraded by interference, the Participants are encouraged (see section 3.12 of document C/S A.005 (MCC Performance Specification and Design Guidelines) to monitor both of the frequency bands that are allocated for System use, and to report any unauthorized active transmissions on either of these frequency bands: • The beacon uplink band between 406.000 MHz and 406.100 MHz, • The satellite downlink band between 1,544.500 MHz and 1,545.500 MHz. This monitoring is usually performed by the Cospas-Sarsat LUTs and is reported to the associated Mission Control Centre. Although there is no formal requirement to distribute these reports, “Ground Segment operators are encouraged to provide monthly interference reports on persistent interferers to the Cospas- Sarsat Secretariat using the reporting format as presented in Annex B at Table B.1, and to provide reports to ITU [International Telecommunication Union] in accordance with their national procedures and ITU requirements.” (See section 5.4 of document C/S A.003, “Cospas-Sarsat System Monitoring and Reporting”. The reporting of interference through national procedures will require some coordination with national regulatory bodies. These bodies, working with ITU, will make whatever effort is necessary to stop the interfering transmissions and to restore the frequency band to its authorized use. MCCs are also encouraged to notify other Ground Segment Providers in the affected area with reports of any interference that they detect. This is done by transmitting an interferer alert message (SIT 121) to all MCCs whose Service Area might be affected by the interferer. F.5.1 In-Band Interference ITU regulations, which are enacted into law in all ITU member states, require that no one use a frequency band except for the authorized purposes. Any transmissions in these bands for purposes that are not related to distress transmissions for satellite detection and for Search and Rescue support are not authorized, and should be reported and suppressed. F-8 F.5.2 Out-Of-Band Interference In addition to the requirement to detect and suppress interference within the frequency bands that are reserved for use by the Cospas-Sarsat System, ITU has recognized that, because of the sensitivity of the System, there should be limitations on transmissions in the frequency bands adjacent to the 406 MHz uplink band, which may cause out-of-band interference. In a paper presented to the Cospas-Sarsat Council in 2019 (CSC-61/OPN/Inf.13), the Secretariat said: “The ITU’s World Radiocommunication Conference 2015 (WRC-15) recognized that unwanted emissions from radiocommunication services outside the frequency band 406 to 406.1 MHz also have a potential to cause interference to space-based MSS receivers within 406 to 406.1 MHz due to the tight link margins of EPIRBs and the considerable cumulative power flux density that could be encountered by a space-based receiver from globally-deployed mobile telephone (and other) stations transmitting in the immediately adjacent bands. Bearing this in mind, WRC-15 decided to revise Resolution 205 to introduce additional protection measures to be applied in the adjacent bands 405.9 to 406.0 MHz and 406.1 to 406.2 MHz.” A circular letter was issued by ITU in December 2018 to implement the revised regulations. This circular letter included a list of the parameters to be monitored, and the periodicity and duration of measurements (as defined in document ITU-R SM.1051-41). MCCs are encouraged to work with their LUT operators to monitor and report on any out-of-band interference that might affect the Cospas-Sarsat System. - END OF ANNEX F - G-1 ANNEX G: COSPAS-SARSAT MODEL COURSE G.1 Purpose of the Model Course The purpose of this model courses is to assist Administrations that operate Mission Control Centres with the development and introduction of MCC Operator training courses. This also includes the updating and improvement of existing courses so that the quality and effectiveness of training may be consistent internationally. It is not the intention of the model course program to present instructors with a rigid “teaching package” but simply to provide guidelines and pointers to useful resources. As in all training endeavours, the knowledge, skills and dedication of the instructors are the key components in the transfer of knowledge and skills to those being trained. Scope This course provides an outline of the training required for those who are designated to perform the duties and responsibilities of an Mission Control Centre operator assigned to a national MCC, as defined in document C/S A.005, Cospas-Sarsat Mission Control Centre (MCC) Performance Specification and Design Guidelines. The purpose of this model course is to assist Administrations in meeting their own training needs, and the obligations they accepted under the International Cospas-Sarsat Programme Agreement, document C/S P.001. G.2 Training Resources The primary training manual for MCC operators is document C/S G.010, MCC Handbook. This manual is supported by a video library available on YouTube and Moodle. Additional manuals and written reference material includes: Document C/S G.003, Introduction to the Cospas-Sarsat System, Document C/S G.004 Cospas-Sarsat Glossary, Document C/S G.007, Handbook on Distress Alert Messages for Rescue Coordination Centres (RCCs), Search and Rescue Points of Contact (SPOCs) and IMO Ship Security Competent Authorities, Document C/S S.007, Handbook of Beacon Regulations, Document C/S S.011, Cospas-Sarsat Glossary, The History and Experience of the International Cospas-Sarsat Programme for Satellite- Aided Search and Rescue. G-2 Operational documentation describing the operation of an MCC includes: 1. Document C/S A.001, Data Distribution Plan (DDP), Document C/S A.002, Cospas-Sarsat Mission Control Centres Standard Interface Description (SID), Document C/S A.003, Cospas-Sarsat System Monitoring and Reporting, Document C/S A.005, Cospas-Sarsat Mission Control Centre (MCC) Performance Specification and Design Guidelines, Document C/S A.006, Cospas-Sarsat Mission Control Centre Commissioning Standard. Videos- available on the Cospas-Sarsat website (hosted on YouTube) and on Moodle (https://moodle.406.org/): 1. Videos about the Programme, Videos and graphics- about owning a beacon, Training videos and graphics: a. RCC Operator Training, b. MCC Operator Training. G.3 Detailed Outline G.3.1 Concept of the Cospas-Sarsat System: a. RCC Operator Training, b. Beacon, Space and Ground Segment, c. System documents, d. System data and statistics. Training resources: • Document C/S G.010, MCC Handbook, • Document C/S G.003, Introduction to the Cospas-Sarsat System, • Video Playlist: Videos About the Programme, - Introduction to the Cospas-Sarsat System, - How Cospas-Sarsat Works, • Video Playlist: About Owning a Beacon. G.3.2 Management of the Cospas-Sarsat Programme: a. Council, Joint Committee, Task Groups and Experts’ Working Groups meetings, b. Programme Agreement and Administrations responsibilities. G-3 Training resources: • The History and Experience of the International Cospas-Sarsat Programme for Satellite-Aided Search and Rescue (https://www.cospas-sarsat.int/en/documents- pro/documents/history-and-experience-of-the-programme), • Document C/S P.001, International Cospas-Sarsat Programme Agreement, • Document C/S G.003, Introduction to the Cospas-Sarsat System, • Video Playlist: Videos About the Programme. G.3.3 Space Segment (LEO, GEO and MEO): a. Status of Space Segment, b. LEOSAR SARP and SARR, c. TCAL, d. Satellite manoeuvres, e. MEOSAR system operation. Training resources: • Cospas-Sarsat website and webpages related to Space Segment status (https://www.cospas-sarsat.int/en/pro / SYSTEM Tab), • Document C/S G.010, MCC Handbook, • Video Playlist: Training Resources. G.3.4 Ground Segment: a. Basic functions of LUTs and MCCs, b. Status of the Ground Segment, c. MEOLUT Hardware / Technology (i.e., parabolic vs phased array antennas). Training resources: • Cospas-Sarsat website and webpages related to Ground Segment status (https://www.cospas-sarsat.int/en/pro / SYSTEM Tab), • Status of the Ground Segment, • Document C/S G.010, MCC Handbook, • Video Playlist: Training Resources. G.3.5 LUTs: a. MCC processing of LUT data, b. MEOLUT Networking, c. Manufacturers’ operational manuals, d. Local LUT operator interface, e. Monitoring of LUTs, f. Orbit and SARP updates, g. Communications to and from LUTs, h. Alarms and warnings from LUTs, G-4 i. Location data concepts and terminology, e.g., Doppler A and B positions, DOA positions, GNSS positions. Training resources: • Cospas-Sarsat website and webpages related to LUTs (https://www.cospas- sarsat.int/en/pro / SYSTEM Tab), • Document C/S G.010, MCC Handbook, • Document C/S T.002, Local User Terminal Performance Specification and Design Guidelines, • Document C/S T.009, GEOLUT Performance Specification and Design Guidelines, • Document C/S T.019, MEOLUT Performance Specification and Design Guidelines, • Video Playlist: Videos About the Programme, • Video Playlist: Training Resources. G.3.6 MCCs: a. Functions of an MCC, b. Manufacturers’ operational manuals, c. Local MCC operator interface, d. Monitoring of MCC operation, e. Communications to and from MCC, f. Alarms and warnings from MCC. Training resources: • Cospas-Sarsat website and webpages related to MCCs (https://www.cospas- sarsat.int/en/pro / SYSTEM Tab), • Document C/S G.010, MCC Handbook, • Document C/S A.001, Data Distribution Plan (DDP), • Document C/S A.002, Mission Control Centres Standard Interface Description (SID) • Document C/S A.003, Cospas-Sarsat System Monitoring and Reporting, • Document C/S A.005, Mission Control Centre (MCC) Performance Specification and Design Guidelines, • Video Playlist: Videos About the Programme, • Video Playlist: Training Resources. G.3.7 Cospas-Sarsat Data Distribution Procedures: a. Concept of service areas, DDRs and nodal MCCs, b. Concept of RCCs and SPOCs and search and rescue regions, c. What to do in case of false alerts, d. Matching and merging of locations: - Doppler to Doppler matching, G-5 - Doppler to encoded matching, - Encoded to encoded matching, - DOA to DOA, - DOA to Doppler, - DOA to encoded, e. Concept of LEO/GEO/MEO alerts, f. MEOSAR average carrier to noise ratio and encoded location error estimate, g. MEOSAR TOA, FOA, TDOA and DOA, h. Error ellipse and Window Factor, i. Data distribution: - 406 MHz Alert Data Distribution Procedures, - Processing Matrices, Message Formats and Distribution of 406 MHz Alerts, - Unlocated, unconfirmed and confirmed alerts, - Conflict alerts, - Continued transmission, - NOCR and SSAS, - ELT(DT) and RLS beacons, j. Data validation: - 406 MHz Alert Message Validation, - Concept of filtering redundant data and better-quality alerts - Based on same beacon event (SBE), poor quality flag indicators, distance criterion and image position determination, - Bit errors and how they are handled, k. Annual System level test (SLT). Training resources: • Document C/S G.010, MCC Handbook, • Document C/S A.001, Data Distribution Plan (DDP), • Document C/S A.002, Mission Control Centres Standard Interface Description (SID), • Document C/S A.003, Cospas-Sarsat System Monitoring and Reporting, • Video Playlist: About Owning a Beacon, • Video Playlist: Training Resources. G.3.8 Cospas-Sarsat Message Formats: a. International character set, b. MCC to MCC message formats and content, c. MCC to RCC/SPOCs (SIT 185 formats), d. Concept of message fields, e. Types of alert messages: - Unconfirmed, confirmed, unlocated, encoded, conflict and NOCR, - Interferer alerts, f. Types of location in SIT 185 messages, G-6 g. System information: - Orbit vectors, TCAL, - SARP calibration, - System status, h. Narrative messages. Training resources: • Document C/S G.010, MCC Handbook, • Document C/S G.007, RCC Handbook, • Document C/S A.001, Data Distribution Plan (DDP), • Document C/S A.002, Mission Control Centres Standard Interface Description (SID), • Video Playlist: Training Resources, • Types of location in SIT 185 messages training resources. CLASSIFICATION ESTIMATED ACCURACY DATA SOURCE REMARKS GNSS Usually 2’’ accuracy (~100m) (see remarks) GNSS Caution with: 1- the refresh rate (see beacon TAC on C/S website), 2- protocol used (user location protocol provides accuracy of 4 min of angle), 3- coarse position only (i.e., PDF-2 is missing) => rounded to 15-min angle (e.g., 50° 30’ N 003° 15’E) DOA See the value of ESTIMATED ERROR. MEOSAR MEOSAR is designed to provide <5km in 95% of the case after 10 min... depending on whether the beacon is moving or static DOPPLER A/B ~10 to 20 km Single LEOSAR pass (or 2 passes on the exact same orbit) Value around 2 positions until the ambiguity is resolved. RESOLVED DOPPLER ~10 to 20 km Multiple LEOSAR passes in different orbits Up to 5 km or even 2 km in the best case, may take some time for the System to derive this position MCC REFERENCE Unknown, depending on the positioning system used (DOA, DOPPLER, GNSS...) MCC REFERENCE accuracy is generally a value close to the accuracy of the DOA and or Doppler location used by the MCC as its reference. G.3.9 Beacons: a. Beacon specifications, b. FGB coding and protocols: G-7 - 15 Hex ID, - User and Location protocols (User, Standard and National), - Orbitography and reference beacons, - Time reference beacon, c. SGB coding: - 23 Hex ID, - SGB benefits to SAR, d. Familiarity with beacon decode app on C/S website, e. Beacon homing and sweep, f. Beacon registration information SIT formats (925,926), g. Importance of beacon registration, h. IBRD- who can register beacons and how to access data (password protected), i. Beacon testing policy, actions to take if live test is requested, j. Beacon disposal, k. Beacon Types and features: - ELT, - ELT(DT), - EPIRB, - PLB, - RLS, - FGB vs SGB, - SSAS. Training resources: • Document C/S G.010, MCC Handbook, • Document C/S G.007, RCC Handbook, • Document C/S S.007, Handbook of Beacon Regulations, • Document C/S A.003, Annex I, System Level Test, • Beacon decoder app on Cospas-Sarsat website, • Beacon coding guide on Cospas-Sarsat website, • Video Playlist: Training Resources, • Video Playlist: About Owning a Beacon. G.3.10 Communications: a. A working knowledge of English to enable timely and effective communications with other MCC operators and the nodal MCC and to ensure understanding of System documents, b. Networks used nationally, c. Network security, d. FTPV Standard, e. AFTN-AMHS Standard, f. Email, g. LUT to MCC communications. G-8 Training resources: • Document C/S G.010, MCC Handbook, • Document C/S G.007, RCC Handbook. G.3.11 Contingency Procedures: a. Back-up procedures – how to enter and exit backup status, b. How to back up another MCC when requested, c. Own back-up MCC and impact on other MCCs, d. LUT data to non-parent MCC, e. Use of email (or other means, e.g., WhatsApp) for transfer of SIT messages, f. Re-routing alert data between MCCs, g. System support staff contact numbers and availability. Training resources: • Document C/S G.010, MCC Handbook, • Document C/S A.001, Data Distribution Plan (DDP). G.3.12 Documentation Set: a. Manufacturers’ LUT and MCC operator manuals: - Operators to acquaint themselves with the contents, b. Cospas-Sarsat documents relevant to MCC operators and available for reference: - Document C/S G.010, MCC Handbook, - Document C/S G.007, RCC Handbook, - Document C/S A.001 – Cospas-Sarsat Data Distribution Plan (DDP), - Document C/S A.002 – Cospas-Sarsat Mission Control Centres Standard Interface Description (SID), - Document C/S A.003 – Cospas-Sarsat System Monitoring and Reporting, - Document C/S T.001 – Specification for Cospas-Sarsat 406 MHz Distress Beacons, - Document C/S T.018 – Specification for Second-Generation Cospas- Sarsat 406-MHz Distress Beacons. G.3.13 Competency Check: [To be determined nationally] G.3.14 On-the-Job Training: The MCC on-the-job training (OJT) is an important way in which MCC operators acquire knowledge to perform their functions at work. It should be performed after completing classroom instruction and should be carried out at the MCC operator station with supervision by a senior operator. To be most effective, an OJT program should include: G-9 G.3.14.1 Working Time Schedule: Documentation of the operator’s work hours. G.3.14.2 Training Plan (subject to be covered): a. List of the MCC operator tasks and competencies, including at least: i. Tasks described at Annex G of document C/S A.006, declaration of DMCC operator capabilities, ii. As applicable, the additional tasks and competencies: ▪ Demonstration of the ability to liaise with nodal MCC and RCCs in English, if appropriate, ▪ Conduct annual System test, ▪ Use of MCC software and local interface, ▪ Interpretation of SIT messages, ▪ Decoding of 15, 22, 23 and 30 Hex messages, ▪ Actions upon receiving QMS warning messages, ▪ Actions to be taken when notified of live beacon tests, ▪ Use of national and international beacon registries (IBRD), ▪ Use of MCC communication facilities (phone, SAR website, fax, etc.), ▪ Statistics recording and reporting, ▪ Case handling and recording, b. List of the nodal MCC operator tasks and competencies, including at least: i. Ensure orbit TCAL and SARP data have been transmitted to the DDR MCCs, ii. On receipt of QMS analysis report, review and transmit appropriate warning, non-conformity and conformity messages and update the Cospas- Sarsat website iii. Aware of manufacturer and Cospas-Sarsat documentation iv. Aware of nodal MCC back-up procedures plus any individual MCC procedures v. Respond to alarms and warnings and any sign of anomalies, especially data distribution anomalies, and seek system manager support if in doubt at any time vi. Focal point for Cospas-Sarsat matters thus have a comprehensive knowledge of the System in general (see Annex G of C/S A.006) vii. Support and assistance to developing MCCs within DDR (see Annex F of C/S A.006) viii. Testing of communication links with all MCCs in DDR and for the back-up DDR (see Annex G of C/S A.006) ix. Monthly communication checks with SPOCs and reporting to Cospas Sarsat Secretariat x. Monitor operation of Cospas Sarsat System in the DDR (see Annex G of C/S A.006) G-10 xi. Constant monitoring of communications within DDR and outside to nodal MCCs xii. Access to foreign language interpreters xiii. Assist system manager in the commissioning of new MCCs, if required xiv. Good knowledge of beacon testing procedures and policy Training resources: • Document C/S G.010, MCC Handbook • Document C/S S.007, Handbook of Beacon Regulations • Document C/S A.003, Annex I, System Level Test • Document C/S A.006, Mission Control Centre Commissioning Standard • Beacon decoder app on Cospas-Sarsat website • Video Playlist: Training Resources G.3.14.3 MCC Operator Checkout and Certification: Upon completion of the practical training portion of the program, the new operator shall be given an MCC Operator Checkout to cover all the items in the Cospas-Sarsat model course. G.3.14.4 Recurrent Training/Recertification a. Operator Recurrent Exam, b. Operator Continuation Training (operator refresher training). - END OF ANNEX G - - END OF DOCUMENT - Cospas-Sarsat Secretariat 1250 René-Lévesque Blvd. West, Suite 4215, Montreal (Quebec) H3B 4W8 Canada Telephone: +1 514 500 7999 Fax: +1 514 500 7996 Email: mail@cospas-sarsat.int Website: http://www.cospas-sarsat.int