MCP/gr-mcp-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
gr-mcp-docs/reference/cospas-sarsat/a-series/a005.md
Ryan Malloy 4ed92efd69 refactor: move spec references out of published site 
Cospas-Sarsat specification summaries moved to reference/ for internal
use only. Links updated to point to official cospas-sarsat.int site.

The extracted images remain in public/ for use in other pages.
2026-02-13 05:03:09 -07:00

61 KiB
Raw Blame History

title description sidebar documentId series seriesName documentType isLatest issue revision documentDate originalTitle
A005: C/S A.005 Issue 5 Rev.5 Official Cospas-Sarsat A-series document A005
badge
text variant
A note
A005 A Operational operational true 5 5 October 2025 C/S A.005 Issue 5 Rev.5

📋 Document Information

Series: A-Series (Operational) Version: Issue 5 - Revision 5 Date: October 2025 Source: Cospas-Sarsat Official Documents

COSPAS-SARSAT MISSION CONTROL CENTRE (MCC) PERFORMANCE SPECIFICATION AND DESIGN GUIDELINES C/S A.005 Issue 5 - Revision 5

Image 1 from page 1

COSPAS-SARSAT MISSION CONTROL CENTRE (MCC) PERFORMANCE SPECIFICATION AND DESIGN GUIDELINES HISTORY Issue Revision Date Comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TABLE OF CONTENTS Page INTRODUCTION ...................................................................................................... 1-1 Overview ............................................................................................................ 1-1 Scope .................................................................................................................. 1-3 Document Organisation ..................................................................................... 1-3 Reference Documents ........................................................................................ 1-4 COSPAS-SARSAT MCC DESCRIPTION .............................................................. 2-1 OPERATIONAL REQUIREMENTS ...................................................................... 3-1 General Operations ............................................................................................ 3-1 Availability ........................................................................................................ 3-2 LUT Coordination .............................................................................................. 3-2 Data Communication Links ............................................................................... 3-2 Data Formats ...................................................................................................... 3-3 Monitoring of National Ground Segment .......................................................... 3-4 Backup Provisions ............................................................................................. 3-4 Re-routing of Messages ..................................................................................... 3-5 Beacon Register ................................................................................................. 3-5 Information Archival and Retrieval ............................................................... 3-6 Test and Exercise Coordination and Reporting ............................................. 3-6 Interference Control ....................................................................................... 3-7 Reference Beacon Operation ......................................................................... 3-7 Reporting Requirements ................................................................................ 3-7 FUNCTIONAL REQUIREMENTS ......................................................................... 4-1 Data Acquisition ................................................................................................ 4-1 Data Validation .................................................................................................. 4-2 Process Data Selectively .................................................................................... 4-2 Position Matching .............................................................................................. 4-2 Position Confirmation ........................................................................................ 4-3 Geographic Sorting of Alert Data ...................................................................... 4-3 Filtering Redundant Alert Data .......................................................................... 4-3 Notification of Country of Beacon Registration (NOCR) ................................. 4-4 Notification of Return Link Service (RLS) Beacon Alerts ................................ 4-4 Notification of Two-Way-Communication (TWC) Beacon Alerts ............... 4-4 Ship Security Alerts ....................................................................................... 4-4 Distress Tracking Alerts ................................................................................ 4-4 Second-Generation Beacon (SGB) Alerts ..................................................... 4-5 Cancellation Messages ................................................................................... 4-5 TAC Related Information on Beacon Characteristics ................................... 4-5 PERFORMANCE REQUIREMENTS ..................................................................... 5-1 Availability ........................................................................................................ 5-1 Communication Links ........................................................................................ 5-1

5.2.1 LUT/MCC ...................................................................................................... 5-1 5.2.2 MCC/MCC ..................................................................................................... 5-2 5.2.3 MCC/Non-MCC Alert Recipient ................................................................... 5-2 Alert Data Processing Capacity ......................................................................... 5-2 System Information Processing Capacity .......................................................... 5-3 Cospas-Sarsat QMS Continuous Monitoring and Objective Assessment Capacity ............................................................................................................................ 5-3 Processing Time ................................................................................................. 5-3 Processing Integrity ........................................................................................... 5-3 Access to Archived Information ........................................................................ 5-4 Backup Timing................................................................................................... 5-4 Additional Timing Requirements .................................................................. 5-4 SPECIFICATIONS FOR NODAL MCCs ............................................................... 6-1 Operational Requirements ................................................................................. 6-1 6.1.1 General ........................................................................................................... 6-1 6.1.2 Communications ............................................................................................ 6-1 6.1.3 Quality Management System (QMS) Continuous Monitoring and Objective Assessment ..................................................................................................... 6-1 6.1.4 Backup Procedures......................................................................................... 6-1 Functional Requirements ................................................................................... 6-2 6.2.1 Data Processing .............................................................................................. 6-2 6.2.2 Geographical Sorting of Alert Data ............................................................... 6-2 6.2.3 System Information Processing ..................................................................... 6-2 6.2.4 Narrative Information Processing .................................................................. 6-2 Performance Requirements ................................................................................ 6-2 6.3.1 Availability .................................................................................................... 6-2 6.3.2 MCC/MCC Communication .......................................................................... 6-3 6.3.3 Alert Processing Capacity .............................................................................. 6-3 Coordinating Requirements ............................................................................... 6-3 LIST OF FIGURES Page Figure 2.1: Typical Cospas-Sarsat MCC Functional Block Diagram .................................. 2-2

1-1

INTRODUCTION Overview The purpose of the Cospas-Sarsat System is to provide distress alert and location data for search and rescue (SAR) by using spacecraft and ground facilities to detect and locate distress signals. The position of the distress and other related information is transmitted to appropriate SAR authorities. Distress beacons (Emergency Locator Transmitters - ELTs, including Distress Tracking ELTs

  • ELT(DT)s, Emergency Position Indicating Radio Beacons - EPIRBs, Ship Safety Alerting System beacons - SSAS, and Personal Locator Beacons - PLBs) transmit signals that are detected by Cospas-Sarsat spacecraft in orbit around the earth. These beacons may be either First-Generation Beacons (FGBs), which are compliant with the specifications of document C/S T.001, or Second-Generation Beacons (SGBs), which are compliant with the specifications of C/S T.018. The signals from these beacons are relayed by the satellites of the Cospas-Sarsat Space Segment to Cospas-Sarsat ground receiving stations, termed Local User Terminals (LUTs), which process the signals to determine the beacon location. Alerts are then relayed, together with location data, via a Mission Control Centre (MCC) to the appropriate destination. The geographical area within which an MCC takes responsibility to distribute Cospas-Sarsat alert data to responsible SAR authorities (i.e., RCCs and SPOCs) is called its service area. The principles applicable to the definition of an MCC service area, its coordination with other MCCs to ensure efficient alert data distribution, and its description for effective implementation of the geo-sorting of alert data by other MCCs, are provided in the document C/S P.011 "Cospas-Sarsat Programme Management Policy", and further expanded in the document C/S A.006 "Cospas-Sarsat MCC Commissioning Standard". An MCC may send alert messages to any of:
  • an MCC that is operated by another Ground Segment Provider,
  • a SPOC or national RCC within its service area,
  • a competent authority designated by a national administration within the MCC's service area for the receipt of SSAS alert messages,
  • a Return Link Service Provider (RLSP) operated by the Space Segment Provider responsible for the Space Segment associated with a particular RLS beacon,
  • a Two-Way-Communication Service Provider (TWC-SP) operated by the Space Segment Provider responsible for the Space Segment associated with a particular TWC beacon,
  • the Location of an Aircraft in Distress Repository (LADR) that is maintained for ICAO. Collectively, these are referred to in this document as "alert data recipients".

1-2

The network of MCCs also distributes system data, including satellite orbit data and configuration information, through the Cospas-Sarsat system. An MCC may send system data messages to any of:

  • an MCC that is operated by another Ground Segment Provider,
  • a LUT operated by its own national administration. Collectively, these are referred to in this document as "system data recipients". "Alert data recipients" and "system data recipients" are together referred to as "data recipients". The Cospas-Sarsat Ground Segment (LUTs and MCCs) is an important link in the search and rescue effort. To be effective it must be organised to ensure:
  • speed (timely distribution of alert data),
  • reliability (distribution of alert data and System information in the event of failure of LUTs or MCCs),
  • accuracy (correctness of information delivered),
  • efficiency (economic and smooth flow of data),
  • accountability (tracking of messages in the Ground Segment). To achieve these objectives, each unit of the Ground Segment must comply with certain standards. The standards contained in this document provide a framework for the functions of the MCC including the exchange of data, performance levels and operating procedures. MCCs that meet specified standards of performance are commissioned to operate within the Cospas- Sarsat Ground Segment. Procedures for processing and exchanging data between MCCs (alert data and System information) and the procedures for distributing data to the appropriate data recipients are defined in document C/S A.001, "Cospas-Sarsat Data Distribution Plan". MCCs are required to apply the procedures described in document C/S A.001 in compliance with the data exchange formats and protocols defined in document C/S A.002, "Cospas-Sarsat Mission Control Centres Standard Interface Description". Furthermore, national agencies and administrations involved must ensure ongoing verification of System operation and performance parameters. The requirements for System monitoring by each Ground Segment operator are defined in document C/S A.003 (System monitoring and reporting), including the format for regular reporting of System status by all MCCs. The data that is sent to the MCC from the LUTs may be received through any of three satellite systems that are intended for search and rescue (SAR) support:
  • LEOSAR Low Earth Orbit (LEO) Search and Rescue,
  • MEOSAR Medium-altitude Earth Orbit (MEO) Search and Rescue,
  • GEOSAR Geostationary Earth Orbit (GEO) Search and Rescue. The data for each of these systems is relayed through dedicated satellites for that system and is received and processed by LUTs that are dedicated to the same system.

1-3

As part of the Cospas-Sarsat System, an MCC is subject to acceptance testing based on this specification, and tests defined in document C/S A.006 (MCC Commissioning Standard). Providing that all requirements are fulfilled, each Ground Segment operator decides on the most suitable means for implementing its MCC. Although this document includes descriptions of the MCC functions that are necessary to support an associated LUT (LEOLUT, MEOLUT or GEOLUT), it is not essential that an MCC have an associated LUT. An MCC with no associated LUT of any particular type is exempted from the requirements to support the functions that are identified in support of that type of LUT. Scope This specification describes the minimal operational, functional and performance requirements of a Cospas-Sarsat MCC. This specification also describes the additional requirements to be met by those MCCs designated as 'nodal' MCCs. Document Organisation The document is structured as follows:

  • section 2 presents an overview of a Cospas-Sarsat MCC,
  • section 3 describes the operational requirements governing the general responsibilities of the MCC relative to the Cospas-Sarsat Ground Segment,
  • section 4 contains functional requirements governing the specific functions to be performed by the MCC,
  • section 5 contains performance requirements applicable to the MCC,
  • section 6 describes the additional requirements for those MCCs designated as 'nodal' MCCs. The acronyms used in this document are contained in the "Cospas-Sarsat Glossary", document C/S S.011.

1-4

Reference Documents The following documents contain useful information pertaining to MCC specifications, and the procedures for integration into the Cospas-Sarsat System: a. C/S A.001 Cospas-Sarsat Data Distribution Plan, b. C/S A.002 Cospas-Sarsat Mission Control Centres Standard Interface Description, c. C/S A.003 Cospas-Sarsat System Monitoring and Reporting, d. C/S A.006 Cospas-Sarsat MCC Commissioning Standard, e. C/S P.011 Cospas-Sarsat Programme Management Policy, f. C/S S.011 Cospas-Sarsat Glossary, g. C/S T.001 Specification for Cospas-Sarsat [First-Generation] Distress Beacons, h. C/S T.002 Cospas-Sarsat LEOLUT Performance Specification and Design Guidelines, i. C/S T.005 Cospas-Sarsat LEOLUT Commissioning Standard, j. C/S T.006 Cospas-Sarsat Orbitography Network Specification, k. C/S T.007 Cospas-Sarsat [First-Generation] Distress Beacon Type Approval Standard, l. C/S T.009 Cospas-Sarsat GEOLUT Performance Specification and Design Guidelines, m. C/S T.010 Cospas-Sarsat GEOLUT Commissioning Standard, n. C/S T.015 Cospas-Sarsat Specification and Type Approval Standard for 406 MHz Ship Security Alert (SSAS) Beacons, o. C/S T.018 Specification for Cospas-Sarsat Second-Generation Distress Beacons, p. C/S T.019 Cospas-Sarsat MEOLUT Performance Specification and Design Guidelines, q. C/S T.020 Cospas-Sarsat MEOLUT Commissioning Standard, r. C/S T.021 Cospas-Sarsat Second-Generation Distress Beacon Type Approval Standard, s. C/S T.022 Guidelines for MEOSAR Reference Beacons, t. C/S R.025 Cospas-Sarsat Two-Way Communication Operational Concept and High-Level Requirements. Other information that is used in this document is contained on the Cospas-Sarsat website, available at http://www.cospas-sarsat.int/en/pro.

  • END OF SECTION 1 -

2-1

COSPAS-SARSAT MCC DESCRIPTION An MCC is part of the Cospas-Sarsat Ground Segment. It collects, sorts and stores data from its associated LUT(s)1 and other MCCs. MCCs are the primary System component that provide for data exchange within the international Cospas-Sarsat System, to other alert data recipients. Alert data is a generic term for Cospas-Sarsat data derived from 406 MHz emergency beacons. Alert data include beacon identification and may contain Independent Location information (computed by the LUT), encoded location data (provided by the beacon), or both. System information is used primarily to keep the Cospas-Sarsat System operating effectively. It consists of satellite ephemeris, time calibration, and frequency calibration data used to determine beacon locations, the current status of the Space and Ground Segments, and co- ordination messages. The MCC is defined in this document as a function. It may be implemented in many ways, such as sharing equipment with other ground segment equipment. At a minimum, it must have the following components:

  • access to, and appropriate interfaces to national and international communication networks,
  • processor(s) to automatically process alert and System data,
  • time reference,
  • operator interface,
  • data archive,
  • staff. A typical MCC functional block diagram is shown in Figure 2.1. An MCC must communicate with its associated LUT(s)1, and with alert data recipients. Therefore, it must maintain as many communication links as are operationally required. A communication link, in the context of this document, is defined as the conceptual link between an MCC and other System components with which it must communicate (as listed above). Document C/S A.001, in a section entitled "Data Distribution Regions", provides details on the structure of the data distribution network that is used in the Cospas-Sarsat System. A communication network is the physical or virtual means by which data is exchanged. Networks are described in detail in document C/S A.002. A single communication link may use one or more networks to meet operational requirements. However, the messages transmitted over this communications link (or these communications links) should contain sequential message numbers, per destination, that are independent of the link that is used to send each message. 1 This applies only to the extent that the MCC has associated LUTs.

2-2

Figure 2.1: Typical Cospas-Sarsat MCC Functional Block Diagram2

  • END OF SECTION 2 - 2 An MCC will also distribute alert data from:
  • an SSAS beacon to the appropriate Competent Authority in the nation where the beacon is registered,
  • an ELT(DT) to the LADR,
  • an RLS beacon to the Return Link Service Provider (RLSP) with which the beacon return link service is associated,
  • a TWC beacon to the Two-Way-Communication Service Provider (TWC-SP) with which the beacon two-way-communication service is associated.

3-1

OPERATIONAL REQUIREMENTS The basic operational objective of an MCC is to receive alert data from its associated LUT(s)3 or other MCCs and distribute this information to the appropriate alert data recipients. General Operations 3.1.1 An MCC shall be responsible for establishing procedures for the distribution of Cospas-Sarsat alert data, System information, and other data within its own service area. 3.1.2 An MCC shall respond to direct requests for information from any alert data recipient. 3.1.3 An MCC shall be capable of accounting for all messages, received or transferred through its own system. 3.1.4 An MCC shall validate all messages and data that it receives, before forwarding that data to an alert data recipient. 3.1.5 An MCC shall be configurable to selectively process or suppress alert data to any alert data recipient. 3.1.6 An MCC shall at all times be able to establish voice communications with other MCCs via the international telephone network. Availability of a facsimile capability is also recommended. 3.1.7 An MCC shall transmit solution data for the McMurdo Station and Longyearbyen orbitography beacons4 received from each of its associated LEOLUTs3 to its nodal MCC in accordance with the Cospas-Sarsat Quality Management System (QMS) continuous monitoring and objective assessment processes5. 3.1.8 An MCC shall transmit solution data for reference beacons designated for QMS4 received from each of its associated GEOLUTs3 to its nodal MCC in accordance with the Cospas-Sarsat QMS continuous monitoring and objective assessment processes5. 3.1.9 An MCC shall transmit solution data for reference beacons designated for QMS4 received from each of its associated MEOLUTs3 to its nodal MCC in accordance with the Cospas-Sarsat QMS continuous monitoring and objective assessment processes5. 3 This applies only to the extent that the MCC has associated LUTs of the indicated type. 4 Information about these reference beacons is available on the Detailed Beacon Types page on the Cospas- Sarsat Professional website, available at http://www.cospas-sarsat.int/en/pro, under the Beacons menu, and in documents C/S T.006 and C/S T.022. 5 These processes are described in document C/S A.003 (System monitoring and reporting) under Methodology and Procedures for Continuous Monitoring and Objective Assessment of Cospas-Sarsat System Status.

3-2

Availability 3.2.1 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. LUT Coordination 3.3.1 An MCC shall be able to receive and process all alert data from its associated LUT(s). 3.3.2 An MCC shall be able to provide System information to its associated LUT(s). Data Communication Links An MCC shall maintain communication links according to operational requirements. 3.4.1 The choice of communication links and networks to be used between an MCC and its associated LUT(s) is a national prerogative. 3.4.2 The choice of communication links and networks to be used between an MCC and its national RCCs is a national prerogative. 3.4.3 The choice of communication links and networks to be used between an MCC and each SSAS Competent Authority is to be determined by bilateral agreement with the Competent Authorities. 3.4.4 The choice of communication links and networks to be used between an MCC and its associated Return Link Service Provider (RLSP) is to be determined by bilateral agreement with the RLSP. 3.4.5 The choice of communication links and networks to be used between an MCC and its associated Two-Way Communication Service Provider (TWC- SP) is to be determined by bilateral agreement with the TWC-SP. 3.4.6 Nodal MCCs shall provide ELT(DT) alert data to the Location of an Aircraft in Distress Repository (LADR) using Web Services, as specified in document C/S A.002. 3.4.7 An MCC shall only use communication networks identified in document C/S A.002 for communications with other MCCs. An MCC shall be capable of receiving text messages in non-SIT format sent by SAR authorities. 3.4.8 An MCC shall maintain communication links with other MCCs for the distribution of information as shown in document C/S A.001. An MCC shall maintain access to at least two international communication networks to allow for backup. An MCC may enter into bilateral agreements with other MCCs with regard to communication networks, protocols, and other communication matters, consistent with requirements of documents C/S A.001 and C/S A.002 and other provisions of this document (C/S A.005).

3-3

3.4.9 An MCC shall 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 arrangements cannot be made for a particular Administration in the MCC service area, the MCC shall notify its own SAR authorities (as appropriate) of any Cospas-Sarsat alert data in that Administration's search and rescue region (SRR) for handling in accordance with national SAR procedures. 3.4.10 For alert data recipients except for other MCCs, and where possible, it is recommended that MCCs maintain access to two communication networks. These communication links and networks should be documented in C/S A.001. 3.4.11 An MCC shall implement communication links consistent with the standards and protocols contained in document C/S A.002. 3.4.12 MCC data communication shall be implemented such that all communication links and networks can operate simultaneously without loss of information. Data Formats 3.5.1 An MCC may communicate in any format with its associated LUT(s) and with its own national RCCs and national SAR agencies. 3.5.2 An MCC shall employ only formats specified in document C/S A.002 for communications with other approved data recipients. 3.5.3 An MCC shall have the capability to send or receive all of the Subject Indicator Type (SIT) messages that are defined in the Standard Interface Description (C/S A.002), except as identified in the following paragraphs. 3.5.4 An MCC shall be capable of receiving, validating, and monitoring (as per the Annex "Performance Parameters for System Self-Monitoring" in document C/S A.003) the SIT 215, SIT 216 and SIT 217 messages (orbit vectors) and SIT 415 and SIT 417 messages (SARP calibration) from other MCCs, and of promptly retransmitting the corresponding SIT 215, SIT 216, SIT 415 and SIT 417 messages data to their associated LEOLUT(s). This is particularly important after any satellite or communication outage that has prevented the MCC from sending this calibration data to the LEOLUT6. 3.5.5 The SIT 416 message and SIT 425 through SIT 545 messages are used by MCCs providing Space Segment resources. The associated MCC of each Space Segment Provider shall be able to send or receive these messages, according to its specific functions and requirements. 6 This applies only to the extent that the MCC has associated LUTs.

3-4

3.5.6 An MCC shall be able to receive (but not necessarily to generate and transmit) the following messages: SIT 121, SIT 141, SIT 925, SIT 926 and SIT 927. 3.5.7 An MCC shall be able to interface with different communication networks (receive a message on one network and retransmit it, possibly after processing, to another contact on a different network), and change the message format, as appropriate (e.g., receive input data from associated LUT(s) and other MCCs and convert to SIT 185 for transmission to a SAR authority). 3.5.8 Messages that require retransmission, but have been received in a non- standard format, shall be transmitted in SIT 915 format. 3.5.9 An MCC shall use the SIT 185 format, as specified in document C/S A.002, to transmit alert messages to SPOCs of Administrations in their service area. Monitoring of National Ground Segment An MCC shall monitor the following System elements in its national Ground Segment. 3.6.1 An MCC shall monitor the performance of its LUT(s) to determine degradation of its operational capability. LUT monitoring guidance is provided in document C/S A.003 (System monitoring and reporting). 3.6.2 An MCC shall monitor the LUT/MCC communication link. The LUT/MCC communication link may be actively monitored (i.e., sending periodic test messages), or passively monitored (e.g., monitoring the time delay between the forecast loss of signal at the LUT and the reception of the alert data at the MCC, or the LUT/MCC data transfer time). 3.6.3 An MCC shall monitor its own operation to ensure availability and to avoid distributing unreliable or corrupted data. 3.6.4 An MCC shall have the capability to monitor external communications with all of its data recipients. 3.6.5 An MCC shall immediately notify all other MCCs if it is unable to receive, process, and transmit data according to Cospas-Sarsat specifications. 3.6.6 Any anomaly detected that might affect the Cospas-Sarsat System shall immediately be reported in accordance with documents C/S A.001 and C/S A.003 (Cospas-Sarsat System Monitoring and Reporting), and backup procedures shall be implemented, as appropriate. Backup Provisions 3.7.1 In the event of a failure of a ground segment element or in case of a scheduled interruption, the MCC concerned shall implement backup procedures, possibly with the assistance of other MCCs, as described in the sections entitled "Contingency Procedures" and "Description of Cospas-Sarsat MCCs" of document C/S A.001. The affected MCC must be capable of informing other participants in the Ground Segment network using status messages as defined in document C/S A.001.

3-5

3.7.2 An MCC shall be implemented such that failure of any associated LUT(s) will not affect the operation of the MCC with regard to reception and handling of alert data from other LUTs and other MCCs. 3.7.3 As an optional capability, the MCC operator may compose and transmit messages (e.g., alert messages) manually in the event of a failure within the MCC, other than a communication system failure. Additionally, MCCs should make bilateral arrangements where necessary to transfer LUT data from other Ground Segment operators in order to maintain the LUT data flow if another MCC fails. Re-routing of Messages An MCC may possess the optional capability to re-route (provide alternate path(s)) messages between two other MCCs when the direct communication link between them fails. When this capability is available, re-routing procedures will be developed and agreed by the participating MCCs in advance of the operational use of message re-routing. Prior to activation of the agreed re-routing procedures, all involved MCCs will be notified. This capability shall be designed such that: a) the SIT message content sent by the originating MCC is the same as it would have been if re-routing were not in effect; b) the SIT message content is preserved by the MCC(s) providing the re-routing service; and c) the "MCC Data Routing Matrix" and "System Information Distribution" as given in the Tables of document C/S A.001are not affected, and the SIT content of the message is not changed by the MCC(s) providing the re-routing service. Beacon Register An MCC shall maintain access to a register of beacons bearing its own country code and other States' country codes, as provided for under bilateral agreements. An MCC shall also be capable of requesting information from States which maintain a beacon register for 406 MHz beacons using a serial coding protocol. An MCC shall be able to retrieve beacon registry data using any of the following parameters:

  • beacon identification (15-Hex ID or 23-Hex ID, per the section entitled "Beacon Identification" of document C/S A.001),
  • mobile identification (MMSI, ship call sign, aircraft registration markings, or aircraft ICAO 24-bit address). An MCC shall respond to requests from other MCCs for register information on beacons within the framework of its national regulations.

3-6

Information Archival and Retrieval An MCC shall be able to archive and retrieve information concerning beacons for which it has received alert data (either from its own LUTs or from other MCCs) and any messages transmitted or received during a defined time-frame. The MCC shall then be capable of retransmitting the appropriate information to the alert data recipient which issued the request. 3.10.1 An MCC shall be able to retrieve alert (beacon) data using any of the following parameters: a) period of time to be covered by database search; b) geographical area, given by (1) a rectangle (with sides running N-S and E-W) defined by latitude and longitude of extremities of one diagonal, or (2) a circle defined by centre and radius; c) beacon identification (15-Hex ID or 23-Hex ID, per the section entitled "Beacon Identification" of document C/S A.001); d) mobile identification (MMSI, ship call sign, aircraft registration, 24- bit aircraft address); e) beacon type (for ELT(DT)s and SSAS beacons); and f) country code. The database interrogation modes shall be (a) + any one of the remaining items from the above list. An MCC may implement other retrieval modes as determined by national needs. 3.10.2 An MCC shall be able to retrieve a Cospas-Sarsat message using any of the following parameters: a) starting time/ending time of the search; b) type of message (incoming or outgoing); c) SIT format; d) message source or destination (MF #2 or MF #5 in document C/S A.002); e) beacon identification (15-Hex ID or 23-Hex ID, per the section entitled "Beacon Identification" of document C/S A.001); f) mobile identification (MMSI, ship call sign, aircraft registration, 24- bit aircraft address); and g) country code. The database interrogation modes shall be either (a) and (e), or (b) and any one of the items from the above list. Test and Exercise Coordination and Reporting An MCC shall be able to participate in tests and exercises following a request from another MCC. The procedure defined in document C/S A.001shall be applied.

3-7

An MCC shall also be capable of collecting and reporting alert data using formats and techniques agreed with the Cospas-Sarsat Joint Committee. Interference Control An MCC shall co-operate with other States participating in Cospas-Sarsat and with the International Telecommunication Union (ITU) through appropriate national channels, in locating and removing interference in the frequency bands used by Cospas-Sarsat. MCCs are encouraged to collect 406-MHz repeater data from their associated LUT(s) to assist in locating 406-MHz interferers in their LUT coverage area(s). An MCC shall report on detected interferers in accordance with guidance provided in document C/S A.003. Reference Beacon Operation When a State provides a reference beacon, including an orbitography beacon (as part of the Cospas-Sarsat orbitography network, as defined in document C/S T.006) or a MEOSAR reference beacon (as defined in document C/S T.022), a designated MCC shall act as operational point of contact for communications with other Cospas-Sarsat MCCs regarding the operation of this beacon. The Administration providing a reference beacon may assign operational responsibility for the beacon to the designated MCC, which includes: control of activation, verification of location, monitoring performance and reporting outages. An MCC shall be capable of receiving data resulting from orbitography or reference beacon transmissions. Reporting Requirements An MCC should be designed to allow the extraction of data used for reporting on system status and performance. The information to be provided on a periodic basis is documented in document C/S A.003; this includes data on availability, beacon activations reported to RCCs/SPOCs, detected sources of interference, and data required for analysis of SAR events.

  • END OF SECTION 3 -

4-1

FUNCTIONAL REQUIREMENTS Document C/S A.001contains detailed information on data distribution procedures. These procedures are part of the functional requirements imposed on Cospas-Sarsat MCCs. The basic functional and processing requirements, which are further described in the sections below, of an MCC are to: a) receive data from its associated LUTs and other MCCs; b) validate alert messages based on format and content; c) selectively process data; d) match distress alert signals emanating from the same beacon source; e) confirm position; f) geographically sort distress alert data to determine the appropriate recipient of the alert data; g) maintain up-to-date configuration about:

  • satellites,
  • LUTs,
  • MCCs,
  • beacon characteristics associated with the type approval certificate numbers,
  • country codes; h) filter redundant distress alert data as described in C/S A.001; i) provide notification of country of beacon registration (NOCR) for 406-MHz beacons as required; j) process ship security alerts; k) process return link service (RLS) beacon alerts; and l) process ELT(DT) alerts. Data Acquisition An MCC shall be capable of receiving, without any loss of data, all uncorrupted messages sent by Cospas-Sarsat LUTs and MCCs and by SAR authorities via any of the networks to which it is connected. Incoming data shall be time tagged with the time of receipt (co-ordinated universal time (UTC)) and stored. Data received electronically shall be stored electronically. In all cases, incoming data shall be accessible to the operator for the period specified in section 5.

4-2

Data Validation 4.2.1 An MCC shall validate all received messages for proper data format and consistency, using the guidelines provided in documents C/S A.001 and C/S A.002. An MCC shall be capable of requesting retransmission of any message that is believed to be in error. If an MCC detects an incomplete message or a message with an incorrect format, the MCC shall filter the anomalous message from the distribution system, notify the MCC which generated the message, and request re- transmission of the (corrected) message. 4.2.2 An MCC shall validate the alert data received from LUTs and MCCs according to the sections "Validation of Beacon Message Data" and "Alert Message Validation (Filtering Anomalous Data)" of document C/S A.001, to ensure that alert data transmitted by the MCC corresponds to real transmissions, and to ensure that an alert was not a system processing anomaly generated by factors such as the incorrect application of System time, invalid error correcting codes or invalid beacon message formats. 4.2.3 An MCC shall validate the location data by performing the satellite footprint check according to the requirements of the section entitled "Alert Data Distribution Procedures" of document C/S A.001. Process Data Selectively 4.3.1 An MCC shall have the capability to process data selectively (filter or transmit data to a specified destination), based on a specified source of data (LUT/MCC), satellite, frequency band, beacon user class (test, orbitography, or operational protocols), or the location/identification characteristics of a transmitting beacon. 4.3.2 An MCC shall be capable of suppressing alert data transmission for a particular beacon when requested to do so by an alert data recipient. 4.3.3 An MCC shall have the capability to filter Doppler or DOA locations, based on a specified source of data (LUT), per beacon generation (FGB or SGB). Position Matching An MCC shall attempt to match distress alert data from the same beacon to confirm the beacon position or to improve the position accuracy. An MCC shall use the criteria contained in the sections entitled "Processing Multiple Alerts for the Same Beacon Identification", "Confirmation of Beacon Positions", "Cancellation Messages" and "Detailed Implementation of Data Distribution Procedures" in document C/S A.001 to match alert data.

4-3

Position Confirmation The objective of the position confirmation process is to confirm the position data contained in a beacon solution on the basis of independent information. Ambiguity resolution is the process of determining which of the two solutions computed by the LEOSAR Doppler processing for each transmitting beacon is the real position and which is the image. 4.5.1 An MCC shall use the criteria contained in the sections entitled "Confirmation of 406 MHz Positions" and "Position Matching" of document C/S A.001 to confirm position for alert data. 4.5.2 An MCC shall use the criteria contained in the sections entitled "Continued Transmission after Position Confirmation" of document C/S A.001 to exchange alert data after position confirmation. 4.5.3 A beacon position may also be confirmed at a national level, subject to direction from SAR forces, using any additional information such as a request for assistance with indication of a probable search area, relation of locations to a beacon message, overflight reports, correlation of land/sea positions with beacon type (i.e., ELT / EPIRB / PLB), overdue reports, etc. Geographic Sorting of Alert Data An MCC shall maintain the capability to geographically sort beacon locations for its service area and those areas required by its communication links as described in document C/S A.001. Each MCC service area shall be sub-divided into Cospas-Sarsat SPOC service areas, as required for application of national procedures. Filtering Redundant Alert Data MCCs shall filter redundant alert data according to criteria defined in the section entitled "Filtering of Redundant Data" of document C/S A.001. The processing of alert data shall follow the procedures for determining better quality LEOSAR or MEOSAR alert independent location data for the same beacon event as contained in the section entitled "Procedures to Determine Better Quality Alert Data for Same Beacon Event Position Conflicts" in that section of document C/S A.001. However, MCCs shall not filter redundant data for the reference beacons designated for QMS7 that are used as part of the Cospas-Sarsat QMS continuous monitoring and assessment process:

  • for the LEOSAR system, the McMurdo and Longyearbyen orbitography beacons are normally used for QMS continuous monitoring and assessment,
  • for the GEOSAR system, one of the reference beacons in Toulouse, Edmonton, or Kerguelen is normally used for QMS continuous monitoring and assessment, 7 Information about the reference beacons is available on the Detailed Beacon Types page on the Cospas-Sarsat Professional website, available at http://www.cospas-sarsat.int/en/pro, under the Beacons menu, and in documents C/S T.006 and C/S T.022.

4-4

  • for the MEOSAR system, these or other beacons may be designated for QMS continuous monitoring and assessment. As noted in document C/S A.003, "Cospas-Sarsat Monitoring and Reporting", alternative beacon(s) that meet the necessary performance requirements may be designated for any LUT that is to be monitored. Notification of Country of Beacon Registration (NOCR) In addition to the distribution of alert data, MCCs shall provide notification to all countries of a distress alert within their service area. MCCs shall follow the procedures contained at the sections entitled "Notification of Country of Beacon Registration (NOCR) Service" and "NOCR Procedures" of document C/S A.001. Notification of Return Link Service (RLS) Beacon Alerts In addition to the distribution of alert data, MCCs shall provide notification of a distress alert within their service area to the designated Return Link Service Provider of the Space Segment Provider for the GNSS system that supports the beacon associated with the alert. MCCs shall follow the procedures contained at the sections entitled "Return Link Service (RLS) Procedures" and "Distribution of Alerts for RLS-Capable FGBs to MCCs that are Not FGB-RLS-Capable" of document C/S A.001. Notification of Two-Way-Communication (TWC) Beacon Alerts In addition to the distribution of alert data, MCCs shall provide notification of a distress alert within their service area to the designated Two-Way-Communication Service Provider of the Space Segment Provider for the GNSS system that supports the beacon associated with the alert. MCCs shall follow the procedures contained at the sections of document C/S A.001 entitled "Return Link Service - Two-Way-Communication (TWC)" and "Distribution of alerts for TWC-capable beacons to MCCs that are not TWC-capable". Ship Security Alerts MCCs shall process ship security alerts according to the logic at the sections entitled "Exchange of Ship Security Alerts" and "Distribution of 406 MHz Ship Security Alerts" of document C/S A.001. Routing of ship security alerts shall be based on the country code contained in the beacon message. Ship security alerts shall be exchanged using the formats and data content for 406-MHz alert messages as contained in document C/S A.002. Distress Tracking Alerts MCCs shall process distress tracking alerts from ELT(DT) beacons (based on either C/S T.001 or C/S T.018) and send the alert data to Distress authorities and to the Location of an Aircraft

4-5

in Distress Repository (LADR) according to the logic at the sections of document C/S A.001 entitled:

  • "Alert Data Distribution Procedures", especially the section "Filtering of Redundant Data for ELT(DT)s",
  • "Distress Tracking Alerts",
  • "Operational Distribution of Alert Data for SGBs and FGB ELT(DT)s". ELT(DT) alert data should be distributed to the Distress authorities and sent to LADR as required by document C/S A.001. Second-Generation Beacon (SGB) Alerts MCCs shall process distress alerts from Second-Generation Beacons (based on C/S T.018) and send the alert data to alert data recipients according to the logic of document C/S A.001, especially the section entitled "Operational Distribution of Alert Data for SGBs and FGB ELT(DT)s". Cancellation Messages Cancellation messages may be sent by ELT(DT) beacons (per either C/S T.001 or C/S T.018) and by Second-Generation Beacons (per C/S T.019). MCCs shall distribute these cancellation messages in accordance with the section entitled "Cancellation Messages" and in the document C/S A.001. TAC Related Information on Beacon Characteristics MCCs shall process Cospas-Sarsat Type Approval Certificate (TAC) related information on beacon characteristics in accordance with the section entitled "Processing Alert Information Based on TAC" in document C/S A.001.
  • END OF SECTION 4 -

5-1

PERFORMANCE REQUIREMENTS The following performance requirements apply to the processing of alert data, alert messages and System information and narrative messages. More specific performance standards may be assigned by national authorities in accordance with their national SAR needs. Availability The MCC shall be available to perform its functions 99.5% of the time over a period of one year. The period of unavailability, or downtime (DT):

  • includes all periods of time where the MCC is unavailable due to a failure or planned maintenance (per document C/S A.001 section "Operational Backup"),
  • excludes periods of time where the MCC is unavailable solely due to a planned backup exercise (per document C/S A.001 section "Backup Test"). Communication Links 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. 5.2.1 LUT/MCC8 5.2.1.1 An MCC shall receive all distress alert data transmitted by a LUT within 10 minutes from the completion of LUT processing 99% of the time. 5.2.1.2 The proportion of messages lost in data transfer shall be less than 0.1%. 5.2.1.3 An MCC shall receive all distress tracking alert data by a LUT within 2 minutes from the completion of LUT processing 99% of the time. 8 These requirements apply only to the LUTs (if any) associated with this MCC.

5-2

5.2.2 MCC/MCC 5.2.2.1 An MCC shall implement data communication links and networks that allow it to transfer data to other MCCs within 10 minutes 99% of the time. 5.2.2.2 The proportion of messages lost or corrupted in data transfer between MCCs shall be less than 0.1%. 5.2.2.3 A communication network with other MCCs shall be available for at least 99% of the time during each calendar day. 5.2.3 MCC/Non-MCC Alert Recipient The MCC to any non-MCC alert recipient communication networks shall be available for at least 95% of the time during each calendar day. Alert Data Processing Capacity 5.3.1 An MCC shall be capable of receiving and processing a minimum of solutions9 from each of its associated LUTs10:

  • 100 solutions during a single LEOSAR satellite pass,
  • 500 solutions over a period of 10 minutes, from each associated MEOLUT,
  • 100 solutions over a period of 10 minutes from each associated GEOLUT. 5.3.2 The number of alert messages that an MCC shall be capable of receiving and processing from other MCCs is determined by a forecast of the volume of alert traffic. This forecast takes into account:
  • the actual and forecast volumes of regional beacon populations,
  • the actual and forecast volumes of the global beacon population,
  • the data distribution procedures outlined in the "Cospas-Sarsat Data Distribution Plan" (C/S A.001). At a minimum, an MCC shall be capable of receiving and processing from other MCCs one hundred (100) alert messages over a period of 10 minutes. 5.3.3 An MCC shall be capable of processing alert data from all sources, as described above, and of generating and transmitting a minimum of 100 solution messages to its associated alert data recipients, within each 10- minute period. 9 The requirement of section 5.3.1 only identifies the minimum MCC alert data processing capabilities and is not intended to reflect the beacon capacity specified for LUTs in documents C/S T.002, "LEOLUT Performance Specification and Design Guidelines", C/S T.009, "GEOLUT Performance Specification and Design Guidelines", or C/S T.019, "MEOLUT Performance Specification and Design Guidelines". 10 This applies only to the LUTs (if any) associated with this MCC.

5-3

System Information Processing Capacity An MCC shall be capable of receiving and sending a minimum of 15 System information messages per day. Cospas-Sarsat QMS Continuous Monitoring and Objective Assessment Capacity An MCC shall transmit solution data in accordance with the QMS continuous monitoring and objective assessment process described in document C/S A.003, as follows, for any LUTs that are associated with the MCC: 5.5.1 An MCC shall transmit solution data received for the McMurdo Station and Longyearbyen orbitography beacons11 from each of its associated LEOLUTs to its associated nodal MCC in a SIT 122 or SIT 125 format, as appropriate. 5.5.2 An MCC shall transmit solution data received for appropriate reference beacons11 from each of its associated GEOLUTs to its nodal MCC in a SIT 122 format. 5.5.3 An MCC shall transmit solution data received for appropriate reference beacons11 from each of its associated MEOLUTs to its nodal MCC in a SIT 142 or SIT 145 format, as appropriate. Processing Time MCC processing time is the time elapsed between the receipt of data at an MCC and the transfer of the outgoing message to the communication link to the appropriate data recipient. An MCC shall process each alert within 5 minutes of reception 99% of the time. Processing Integrity 5.7.1 The MCC processing shall contribute no more than 0.2 km to the position error of locations received from a LUT or an MCC. 5.7.2 An MCC shall geographically sort beacon locations and distribute all alert messages to the correct alert data recipient, to within the tolerance of + 25 km of the agreed boundary of MCC service area or SRR. 5.7.3 An MCC shall maintain a time reference accurate to within + 25 seconds. 5.7.4 An MCC shall not corrupt transiting data. 11 Information about the reference beacons is available on the Detailed Beacon Types page on the Cospas-Sarsat Professional website, available at http://www.cospas-sarsat.int/en/pro, under the Beacons menu, and in documents C/S T.006 and C/S T.022.

5-4

Access to Archived Information An MCC shall maintain access to beacon data and alert messages. The following times shall apply: 5.8.1 MCCs shall archive alert data and messages for at least 30 days. 5.8.2 MCC shall respond to requests for archived data and messages from a data recipient within 60 minutes. 5.8.3 MCCs shall respond to requests for alert data and messages covering the preceding 48-hour period within 30 minutes. Backup Timing A failed MCC shall switch its operations to a backup system, and the timing of the switch shall be planned to ensure that the MCC will meet the requirement of the Cospas-Sarsat Programme Management Policy (C/S P.011) that "the capability of an MCC to continuously deliver alert messages shall not be interrupted for longer than one hour". In order to meet this requirement, and to allow some time to diagnose interruptions in alert message delivery, all affected MCCs shall implement backup procedures within 30 minutes of notification. Additional Timing Requirements An MCC shall be designed to allow for the following timing requirements: 5.10.1 10 minutes to suppress alert data. This includes the suppression of alert data in response to notification of a SARP failure and notification of a QMS location accuracy failure. 5.10.2 60 minutes to complete backup procedures such that continuous delivery of alert messages is not interrupted for longer than one hour. 5.10.3 15 minutes to forward a request for information to the national beacon register. 5.10.4 15 minutes to forward retrieved information to the requesting authority. 5.10.5 Update associated LEOLUTs with new orbital data after notification that a LEOSAR satellite manoeuvre has occurred and to provide notification to RCCs and SPOCs of a satellite, per the C/S A.001 section entitled "Scheduled Satellite Manoeuvres": a) immediately upon receipt of a SIT 216 message, when notification of the manoeuvre is received at least 4 hours in advance of the time of the manoeuvre; and b) within four (4) hours of receipt of a SIT 216 message, when notification of a satellite manoeuvre is not provided at least 4 hours prior to the time of the manoeuvre.

5-5

5.10.6 Four (4) hours to update associated LEOLUTs with new SARP time and frequency calibration information after notification that a SARP reset has occurred and the provision of new (SIT 415 or SIT 417) SARP time and frequency calibration information.

  • END OF SECTION 5 -

6-1

SPECIFICATIONS FOR NODAL MCCS In addition to the requirements contained in the preceding sections, nodal MCCs shall comply with the following operational, functional, performance and co-ordinating requirements. Operational Requirements 6.1.1 General A nodal MCC shall be staffed with on-site personnel 24 hours a day to maintain the nodal function. 6.1.2 Communications A nodal MCC shall have access to as many types of communication links as required by the Data Distribution Region (DDR) communication structure, and as required by the nodal MCC network structure. A nodal MCC shall have the capability to send and receive data simultaneously on each communication medium that is used. This may be implemented by having more than one independent communications link, multiple lines supporting one communication link or by having one or more communications service which supports simultaneous reception and transmission of data. 6.1.3 Quality Management System (QMS) Continuous Monitoring and Objective Assessment A nodal MCC shall monitor the operation of the Cospas-Sarsat System within its DDR and take appropriate action when an anomaly is detected. Monitoring includes a verification of receipt of data from MCCs within its DDR within a reasonable time (e.g., some message(s) should be received from an MCC within any eight-hour period). If any anomaly is detected, the nodal MCC shall report the problem to the MCC involved for action. A nodal MCC shall implement the analysis and reporting processes for the Continuous Monitoring and Objective Assessment of Cospas-Sarsat System Status that are described in document C/S A.003. 6.1.4 Backup Procedures A nodal MCC shall develop a detailed backup plan which will be documented in the section entitled "Contingency Procedures" of document C/S A.001. The continuation of the distribution of alert data normally provided by the nodal MCC could be implemented through bilateral arrangements with other MCCs within the same DDR, or with other nodal MCCs. MCCs that assume the role of a backup nodal MCC shall ensure that the minimum agreed operational functionality of the failed node is retained in contingency situations.

6-2

Functional Requirements 6.2.1 Data Processing 6.2.1.1 A nodal MCC shall be capable of receiving and processing alert data from other nodal MCCs, from other MCCs within its DDR, in addition to alert data received from its national or associated LUTs. 6.2.1.2 A nodal MCC shall maintain the integrity of data transiting its system. 6.2.2 Geographical Sorting of Alert Data A nodal MCC shall maintain the capability to geographically sort beacon locations for all MCC service areas within its DDR, and for all other DDRs as necessary. 6.2.3 System Information Processing 6.2.3.1 A nodal MCC shall be capable of receiving, processing and transmitting System information. A nodal MCC shall follow the System information routing described in document C/S A.001. 6.2.3.2 A nodal MCC shall validate System information (satellite ephemeris and calibration data) received from other nodal MCCs and transmit the validated information to other nodal MCCs and to MCCs within its DDR, as specified in the document C/S A.001. System information is validated to ensure the accuracy of the alert data provided by the Cospas-Sarsat System to the SAR community. The criteria used to validate System information are provided in the Annex D "Performance Parameters for System Self-Monitoring" of document C/S A.003 (System monitoring and reporting). Suspected invalid information shall be reported to the MCC which generated the original System information. 6.2.4 Narrative Information Processing A nodal MCC shall route SIT 915, SIT 925, SIT 926 and SIT 927 messages in accordance with the requirements of the DDP (C/S A.001) and the annexes of document C/S A.002. When a SIT 915, SIT 925, SIT 926, or SIT 927 message transits a nodal MCC, the nodal MCC shall set the Message Header (Message Fields #1, #2 and #3, as defined in the section "Cospas-Sarsat Message Text" and the associated annexes of document C/S A.002) to reflect its transmission of the message to the Destination MCC. Performance Requirements 6.3.1 Availability The nodal MCC's functions shall be available 99.5% of the time over a period of one year.

6-3

6.3.2 MCC/MCC Communication The inter-nodal MCC communication availability shall be 99.5% of the time during each calendar day (i.e., a nodal MCC must have at least one communication network available with other nodal MCCs identified in document C/S A.001, 99.5% of the time during each calendar day). 6.3.3 Alert Processing Capacity 6.3.3.1 A nodal MCC shall be capable of processing the alert data from its associated LUT(s) and from other MCCs as outlined in document C/S A.001 taking into account the performance requirements for alert data processing capacity contained in section 5 of this document. 6.3.3.2 A nodal MCC shall be capable of transmitting the number of alert messages as determined by the forecast of regional traffic associated with the network structure defined in document C/S A.001. Coordinating Requirements 6.4.1 A nodal MCC shall co-ordinate the development of the communication links with the MCCs in its DDR. This co-ordination shall include, for example, the types of communication media to be used for intra-DDR communication, and the structure of the DDR communication network. 6.4.2 A nodal MCC shall act as the focal point within its DDR for the distribution of operational Cospas-Sarsat System information and shall provide assistance to the MCCs within its DDR on Cospas-Sarsat matters. A nodal MCC shall provide information and guidance on Cospas-Sarsat System matters, as required. A nodal MCC shall encourage within its DDR the establishment of 406-MHz beacon registries and the registration of 406-MHz beacons. 6.4.3 A nodal MCC shall provide support and assistance to developing MCCs within its DDR. This assistance includes conducting the commissioning tests for a new MCC, reviewing and completing the commissioning report, and forwarding the commissioning report to the Secretariat for review by the Joint Committee.

  • END OF SECTION 6 -
  • END OF DOCUMENT -

Cospas-Sarsat Secretariat 1250 boulevard Rene-Levesque West, Suite 4215, Montreal, Quebec H3B 4W8 Canada Telephone: + 1 514 500 7999 Fax: + 1 514 500 7996 Email: mail@cospas-sarsat.int Website www.cospas-sarsat.int