Ryan Malloy
4ed92efd69
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.
1095 lines
61 KiB
Markdown
1095 lines
61 KiB
Markdown
---
|
|
title: "A005: C/S A.005 Issue 5 Rev.5"
|
|
description: "Official Cospas-Sarsat A-series document A005"
|
|
sidebar:
|
|
badge:
|
|
text: "A"
|
|
variant: "note"
|
|
# Extended Cospas-Sarsat metadata
|
|
documentId: "A005"
|
|
series: "A"
|
|
seriesName: "Operational"
|
|
documentType: "operational"
|
|
isLatest: true
|
|
issue: 5
|
|
revision: 5
|
|
documentDate: "October 2025"
|
|
originalTitle: "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](https://www.cospas-sarsat.int/en/documents-pro/system-documents)
|
|
|
|
---
|
|
|
|
COSPAS-SARSAT
|
|
MISSION CONTROL CENTRE (MCC)
|
|
PERFORMANCE SPECIFICATION
|
|
AND DESIGN GUIDELINES
|
|
C/S A.005
|
|
Issue 5 - Revision 5
|
|
|
|
|
|
|
|
|
|
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 |