---
title: "R012: C/S R.012 - Issue 1 Rev 17"
description: "Official Cospas-Sarsat R-series document R012"
sidebar:
badge:
text: "R"
variant: "note"
# Extended Cospas-Sarsat metadata
documentId: "R012"
series: "R"
seriesName: "Reports"
documentType: "report"
isLatest: true
issue: 1
revision: 17
documentDate: "April 2023"
originalTitle: "C/S R.012 - Issue 1 Rev 17"
---
> **📋 Document Information**
>
> **Series:** R-Series (Reports)
> **Version:** Issue 1 - Revision 17
> **Date:** April 2023
> **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents)
---
COSPAS-SARSAT 406 MHz MEOSAR
IMPLEMENTATION PLAN
C/S R.012
Issue 1 – Revision 17
COSPAS-SARSAT 406 MHz MEOSAR IMPLEMENTATION PLAN
REVISION HISTORY
Issue
Revision Date
Comments
Approved by Council at the CSC-33 Session
Approved by Council at the CSC-35 Session
Approved by Council at the CSC-37 Session
Approved by Council at the CSC-39 Session
Approved by Council at the CSC-41 Session
Approved by Council at the CSC-43 Session
Approved by Council at the CSC-45 Session
Approved by Council at the CSC-47 Session
Approved by Council at the CSC-49 Session
Approved by Council at the CSC-51 Session
Approved by Council at the CSC-53 Session
Approved by Council at the CSC-55 Session
Approved by Council at the CSC-57 Session
Approved by Council at the CSC-59 Session
Approved by Council at the CSC-61 Session
Approved by Council at the CSC-62 Session
Approved by Council at the CSC-64 Session
Approved by Council at the CSC-68 Session
TABLE OF CONTENTS
Page
Document History ....................................................................................................................... i
Table of Contents ....................................................................................................................... ii
1.
Introduction ............................................................................................................. 1-1
1.1
Background ................................................................................................. 1-1
1.2
Purpose and Scope of Document ................................................................ 1-2
1.3
Management and Maintenance of the MEOSAR Implementation
Plan (MIP) .................................................................................................. 1-3
1.4
Reference Documents ................................................................................. 1-3
2.
Description of the MEOSAR System .................................................................... 2-1
2.1
MEOSAR Concept of Operations .............................................................. 2-1
2.2
MEOSAR Space Segment .......................................................................... 2-2
2.3
MEOSAR Ground Segment ....................................................................... 2-3
2.4
MEOSAR Link Budget .............................................................................. 2-4
2.5
MEOSAR 406 MHz Beacon Location Accuracy and Responsiveness ...... 2-4
2.6
Advanced Capabilities ................................................................................ 2-5
2.7
DASS .......................................................................................................... 2-5
2.8
SAR/Galileo ............................................................................................... 2-6
2.9
SAR/Glonass .............................................................................................. 2-8
2.10
SAR/BeiDou ............................................................................................... 2-8
3.
MEOSAR Compatibility and Interoperability .................................................... 3-1
3.1
System Compatibility and Interoperability Concepts ................................. 3-1
3.2
Definition of MEOSAR System Compatibility and Interoperability ......... 3-2
3.3
MEOSAR Compatibility and Interoperability Requirements .................... 3-2
4.
Programme Management and Coordination ....................................................... 4-1
4.1
Development and Integration of the MEOSAR System ............................. 4-1
4.2
Institutional / Management Structure for the Operational
MEOSAR System ....................................................................................... 4-2
5.
Cospas-Sarsat Requirements for a MEOSAR System ........................................ 5-1
5.1
Fundamental MEOSAR Requirements ...................................................... 5-1
5.2
Minimum MEOSAR Performance Levels for Cospas-Sarsat
Compatibility .............................................................................................. 5-1
5.3
Enhanced MEOSAR Performance Objectives ........................................... 5-2
5.4
Evaluation of MEOSAR Performance ....................................................... 5-6
6.
MEOSAR Payloads ................................................................................................ 6-1
6.1
MEOSAR Downlinks ................................................................................. 6-1
6.2
MEOSAR Interference to Existing Users ................................................... 6-3
6.3
Interference to MEOSAR Downlinks ........................................................ 6-4
6.4
Payload Characteristics for MEOSAR Constellations
Interoperability ........................................................................................... 6-7
7.
Advanced MEOSAR System Capabilities ............................................................ 7-1
7.1
MEOSAR Return Link ............................................................................... 7-1
7.2
Implementation of the SAR Galileo Return Link ....................................... 7-5
7.3
Improved 406 MHz Beacon Signals ......................................................... 7-18
8.
MEOSAR Ground Segment ................................................................................... 8-1
8.1
MEOSAR Ground Segment Concept and Architecture ............................. 8-1
8.2
MEOLUT Requirements ............................................................................ 8-4
9.
MEOSAR System Calibration ............................................................................... 9-1
9.1
Satellite Payload Calibration ...................................................................... 9-1
9.2
Signal Path Delay ....................................................................................... 9-1
9.3
MEOLUT Time Measurement Calibration ................................................ 9-1
9.4
MEOLUT Frequency Measurement Calibration ........................................ 9-1
10.
Procedures for MEOSAR Introduction into Cospas-Sarsat ............................ 10-1
10.1
Definition and Development Phase .......................................................... 10-1
10.2
Proof of Concept / In-orbit Validation Phase ........................................... 10-2
10.3
Demonstration and Evaluation Phase (D&E) ........................................... 10-3
10.4
Early Operational Capability (EOC) ........................................................ 10-5
10.5
Initial Operational Capability (IOC)......................................................... 10-6
10.6
Full Operational Capability (FOC) ........................................................... 10-7
10.7
MEOSAR Implementation Schedule ....................................................... 10-7
LIST OF ANNEXES
Annex A: List of Abbreviations and Acronyms and Definitions ........................................ A-1
Annex B: Preliminary DASS Transponder Characteristics................................................. B-1
Annex C: Preliminary SAR/Galileo Transponder Characteristics ...................................... C-1
Annex D: Preliminary SAR/Glonass Requirements and Preliminary Transponders’
Characteristics ..................................................................................................... D-1
Annex E: Minimum Performance Requirements for MEOSAR Compatibility
with the 406 MHz Cospas-Sarsat System ........................................................... E-1
Annex F: MEOSAR Space Segment Interoperability Parameters ...................................... F-1
Annex G: Preliminary MEOLUT Interoperability Parameters ........................................... G-1
Annex H: Work Plan for MEOSAR System Development and Integration in Respect
of Technical and Operational Matters ................................................................. H-1
Annex I: Tentative Time Line of MEOSAR Implementation ............................................ I-1
Annex J: Sample MEOSAR Constellation Link Budget .................................................... J-1
Annex K: List of Actions for the Development and Integration of a MEOSAR System
into Cospas-Sarsat ............................................................................................... K-1
Annex L: Preliminary MEOLUT Network Architecture and Burst Data Requirements .... L-1
Annex M: Draft Definitions of Burst Data Elements and Associated Message Fields
Descriptions ........................................................................................................ M-1
Annex N: Possible MEOSAR System Performance Parameters ......................................... N-1
Annex O: Annex Removed .................................................................................................. O-1
Annex P: Annex F of document C/S A.002 modified to account for MEOLUT
TOA/FOA data transfer ....................................................................................... P-1
Annex R: Preliminary SAR/BDS Transponder Characteristics .......................................... R-1
LIST OF FIGURES
Figure 2.1:
MEOSAR System Concept of Operations ...................................................... 2-2
Figure 2.2:
SAR/Galileo System Concept ......................................................................... 2-7
Figure 2.3:
SAR/Galileo Payload Functions ...................................................................... 2-7
Figure 5.1:
Coverage Area of a Single Standalone MEOLUT
(non-networked MEOLUT) ............................................................................ 5-4
Figure 6.1:
1544 – 1545 MHz Band Plan .......................................................................... 6-2
Figure 6.2:
Cospas-Sarsat LEOSAR and GEOSAR Susceptibility Mask
for 1544 – 1545 MHz Band ............................................................................. 6-3
Figure 7.1:
Overview of the SAR/Galileo Return Link Service
within the Cospas-Sarsat System Architecture ............................................... 7-1
Figure 7.2:
Facilities Contributing to the Return Link Acknowledgment Service ............ 7-4
Figure 7.3:
Galileo Return Link Service In-Orbit Validation Concept ............................. 7-6
Figure 7.4:
RLS Location Protocol Format ....................................................................... 7-8
Figure 7.5:
Return Link Message Structure ..................................................................... 7-10
Figure 7.6:
RLS Data Exchange Overview ..................................................................... 7-14
Figure A.1: Proposed MEOSAR Terminology ................................................................. A-4
Figure H.1: Summary of Work Plan for Technical and Operational Matters ................... H-4
Figure L.1:
Primary Topology of the MEOLUT Network ................................................. L-1
Figure M.1: XML Schema for the transfer of TOA/FOA data between MEOLUTs ........... M-6
LIST OF TABLES
Table 2.1:
Characteristics of MEOSAR Satellite Constellations ..................................... 2-3
Table 5.1:
Performance of Combined DASS and SAR/Galileo Constellations ............... 5-3
Table 6.1:
DASS Payload Downlink Characteristics ....................................................... 6-1
Table 6.2:
SAR/Galileo Payload Downlink Characteristics ............................................. 6-2
Table 6.3:
SAR/Glonass Payload Downlink Characteristics ........................................... 6-2
Table 6.4:
SAR/BDS Payload Downlink Characteristics ................................................. 6-2
Table 7.1:
Cospas-Sarsat and Galileo Interfaces involved in the Return Link
Acknowledgment Service ............................................................................. 7-16
1-1
1.
INTRODUCTION
1.1
Background
Cospas-Sarsat is an international satellite system for search and rescue (SAR) distress alerting
that was established in 1979 by Canada, France, the USA and the former USSR. Since its
inception the Cospas-Sarsat Programme has continually expanded.
The System was originally comprised of satellites in Low-altitude Earth Orbit (LEO). The
LEO satellites and associated ground receiving stations (hereafter referred to as the LEOSAR
system) are compatible with distress beacons operating at 406 MHz. The LEOSAR system
calculates the location of distress beacons using the Doppler effect on the received beacon
signals. Because of LEOSAR satellite orbit patterns, there can be delays between beacon
activation and the generation of an alert message.
In 1998, following several years of testing, the Cospas-Sarsat Council decided to augment the
LEOSAR system by formally incorporating SAR instruments on geostationary satellites for
detecting 406 MHz beacons (hereafter referred to as the GEOSAR system). Geostationary
satellite footprints are fixed with respect to the Earth’s surface, therefore, each satellite provides
continuous coverage over the geographic region defined by its footprint. This reduces the
detection delays associated with the LEOSAR system. Because of their altitude each GEOSAR
satellite provides coverage of a very large area (about one third the surface of the Earth
excluding the Polar Regions). However, because of these attributes (i.e. stationary with respect
to the Earth and high altitude):
•
GEOSAR systems provide location information only if this information is available
from an external source (i.e. global navigation receiver in the beacon) and transmitted
in the 406 MHz beacon message;
•
obstructions blocking the beacon to satellite link cannot be overcome because the
satellite is stationary with respect to the beacon; and
•
the beacon to satellite to LUT communication link budget is not as robust as the
LEOSAR case because of the greater distances involved.
In 2000 the USA, the European Commission (EC) and Russia began consultations with Cospas-
Sarsat regarding the feasibility of installing 406 MHz SAR instruments on their respective
medium-altitude Earth orbit navigation satellite systems (hereafter referred to as MEOSAR
constellations), and incorporating a 406 MHz MEOSAR capability in Cospas-Sarsat. The USA
MEOSAR programme is called the Distress Alerting Satellite System (DASS), the European
System is called SAR/Galileo, and the Russian programme is referred to as SAR/Glonass.
The initial investigations identified many possible SAR alerting benefits that might be realised
from a MEOSAR system, including:
•
near instantaneous global coverage with accurate independent location capability,
1-2
•
robust beacon to satellite communication links, high levels of satellite redundancy and
availability,
•
resilience against beacon to satellite obstructions, and
•
the possible provision for additional (enhanced) SAR services.
In light of this potential, the Cospas-Sarsat Council decided to prepare for the introduction of
a MEOSAR capability into the Cospas-Sarsat System, and to develop this implementation plan.
In 2017, China announced its intent to provide additional elements to the MEOSAR space
system and allow for a MEOSAR capability onboard its BeiDou (hereafter referred to BDS)
navigation constellation satellites.
1.2
Purpose and Scope of Document
The plan addresses all matters that impact upon the possible introduction of a 406 MHz
MEOSAR capability into the Cospas-Sarsat System, including the compatibility of MEOSAR
constellations with each other and with the Cospas-Sarsat System. It includes:
a.
a generic description of the MEOSAR system and detailed information specific to the
DASS, SAR/BDS, SAR/Galileo and SAR/Glonass constellations (section 2);
b.
definitions for MEOSAR system compatibility and interoperability, and a discussion of
the importance of DASS, SAR/BDS, SAR/Galileo, and SAR/Glonass compatibility and
interoperability (section 3);
c.
the management structure and policies agreed by the Cospas-Sarsat Council for
coordinating the development and introduction of MEOSAR components into the
Cospas-Sarsat System (section 4);
d.
the minimum acceptable MEOSAR search and rescue operational performance
requirements for integrating the MEOSAR system into Cospas-Sarsat, and enhanced
performance objectives that might also be achievable (section 5);
e.
an analysis of technical issues relating to MEOSAR payloads (section 6);
f.
a description and status of advanced SAR services that might be provided by a
MEOSAR system (section 7);
g.
a description of the issues which impact upon the design and architecture of a MEOSAR
ground segment (section 8);
h.
an overview of MEOSAR system calibration requirements and methods (section 9);
and
i.
a description of the various MEOSAR implementation and integration phases, i.e.
definition and development, proof of concept/in-orbit validation, demonstration and
evaluation, etc. (section 10).
1-3
This document also serves as a repository for action items relevant to the possible integration
of MEOSAR satellite constellations and ground segment equipment into the Cospas-Sarsat
System.
1.3
Management and Maintenance of the MEOSAR Implementation Plan (MIP)
In this document the term “MEOSAR provider” designates the USA for DASS, China for
SAR/BDS, the European Commission representing the European Union for SAR/Galileo and
the Russian Federation for SAR/Glonass.
Cospas-Sarsat will apply the following principles to the management and maintenance of this
document:
a.
information and changes to information concerning a specific MEOSAR component
will be provided by the respective MEOSAR provider;
b.
information and changes to information pertaining to MEOSAR compatibility with
Cospas-Sarsat and the interoperability of MEOSAR components will be coordinated
and accepted by all MEOSAR providers; and
c.
other aspects of MEOSAR system development will be coordinated with the
MEOSAR providers.
1.4
Reference Documents
a.
C/S G.003:
Introduction to the Cospas-Sarsat System;
b.
C/S S.011:
Cospas-Sarsat Glossary;
c.
C/S T.001:
Specification for Cospas-Sarsat 406 MHz Distress Beacons;
d.
C/S T.002:
Cospas-Sarsat LEOLUT Performance Specification and Design
Guidelines;
e.
C/S T.003:
Description of the Payloads Used in the Cospas-Sarsat LEOSAR
System;
f.
C/S T.005:
Cospas-Sarsat LEOLUT Commissioning Standard;
g.
C/S T.009:
Cospas-Sarsat GEOLUT Performance Specification and Design
Guidelines;
h.
C/S T.010:
Cospas-Sarsat GEOLUT Commissioning Standard;
i.
C/S T.011:
Description of the 406 MHz Payloads Used in the Cospas-Sarsat
GEOSAR System;
j.
C/S T.012:
Cospas-Sarsat 406 MHz Frequency Management Plan;
k.
C/S T.014:
Cospas-Sarsat Frequency Requirements and Coordination Procedures;
and
l.
The International Cospas-Sarsat Programme Agreement (1988).
1-4
- END OF SECTION 1 -
2-1
2.
DESCRIPTION OF THE MEOSAR SYSTEM
The MEOSAR system will provide an enhanced distress alerting capability, characterised by:
•
near instantaneous global detection and independent locating capability for Cospas-
Sarsat 406 MHz distress beacons;
•
high levels of space and ground segment redundancy and availability;
•
robust beacon to satellite communication links;
•
multiple and continuously changing beacon / satellite links, thereby providing
flexibility against beacon to satellite obstructions, and resilience to interference; and
•
a possible return link to the 406 MHz beacon.
This section provides a general description of a MEOSAR system focusing on the aspects
common to the DASS, SAR/BDS, SAR/Galileo and SAR/Glonass systems, and also presents
a description of the characteristics that are unique to each constellation.
2.1
MEOSAR Concept of Operations
Using networks of SAR instruments on satellites and ground processing stations, the MEOSAR
system will receive, decode and locate 406 MHz distress beacons throughout the world. All
four MEOSAR constellations will be completely compatible with Cospas-Sarsat 406 MHz
distress beacons as defined in document C/S T.001 (Cospas-Sarsat beacon specification).
MEOSAR satellites orbit the earth at altitudes of around 20,000 km receiving the signals
transmitted by Cospas-Sarsat 406 MHz distress beacons. The satellite downlinks are processed
by ground receiving stations, hereafter referred to as MEO system Local User Terminals or
MEOLUTs, to provide beacon identification and location information. The distress alert
information computed by MEOLUTs is forwarded to Cospas-Sarsat Mission Control Centres
(MCCs) for distribution to SAR services.
Each MEOSAR satellite provides visibility of a large portion of the surface of the Earth.
Furthermore, because of the large number of satellites in each constellation, and the orbital
planes selected, the DASS, SAR/BDS, SAR/Galileo and SAR/Glonass constellations could
individually provide continuous coverage of the entire Earth, subject to the availability of
suitably located MEOLUTs. Each of the four MEOSAR constellations could support near
instantaneous distress alerting, although a short processing time may be required before an
independent location of the distress beacon becomes available. Information specific to the
DASS, SAR/BDS, SAR/Galileo and SAR/Glonass satellite constellations is provided at
sections 2.7, 2.10, 2.8 and 2.9 respectively.
2-2
Figure 2.1: MEOSAR System Concept of Operations
In addition to the distress alerting function, MEOSAR providers are investigating the feasibility
of providing advanced capabilities, which might include:
•
a return link to the beacon to support additional functions; and
•
new generation 406 MHz beacons.
The advanced capabilities under consideration are introduced at section 2.6, and are discussed
in greater detail at section 7.
2.2
MEOSAR Space Segment
MEOSAR satellites orbit the Earth at altitudes ranging from 19,000 to 24,000 km. The
characteristics of the four MEOSAR satellite constellations are summarised at Table 2.1. The
primary missions for the satellites used in the four MEOSAR constellations are BDS, the
Global Positioning System (GPS), Galileo and Glonass global navigation satellite systems. As
a secondary mission, the SAR payloads will be designed within the constraints imposed by the
navigation payloads.
The four MEOSAR satellite constellations will utilise transparent repeater instruments to relay
406 MHz
beacon
signals,
without
onboard
processing,
data
storage,
or
demodulation/remodulation. The DASS, SAR/BDS, SAR/Galileo and SAR/Glonass payloads
will operate with downlinks in the 1544 – 1545 MHz band. A description of the issues that
influence the selection of MEOSAR downlinks, and the frequency plan for MEOSAR
downlinks are provided at section 6.
Each of the four satellite constellations will require equipment on the ground for satellite /
payload control (i.e. sending commands for satellite station keeping, turning instruments on
406 MHz Beacon
Cospas-Sarsat
MEOLUT
MEOSAR Return
Link to Beacon
Cospas-Sarsat
MCC
2-3
and off, reconfiguring instruments as required, monitoring payload health etc.). This
equipment, which is required for satellite housekeeping, is not considered part of the MEOSAR
system, and is not discussed further unless specific services for SAR are integrated into these
ground stations.
Table 2.1 - Characteristics of MEOSAR Satellite Constellations
SAR/BDS
DASS
SAR/Galileo
SAR/Glonass
Number of satellites:
Total
Operational
In-orbit Spare
With MEOSAR Payloads
TBD
All GPS
Block III
Satellites
TBD
TBD (3)
All Glonass-K
Satellites
Altitude (km)
21,528
20,182
23,222
19,140
Period (min)
Orbital Planes:
Number of Planes
No of Sat. Per Plane (1)
Plane Inclination (degrees)
55º
55º
9 (2)
56º
64.8º
Notes:
1 Not including spare satellites
2 Plus one spare in each plane
3 TBD - To Be Determined
2.3
MEOSAR Ground Segment
A detailed discussion of issues pertaining to the MEOSAR system ground segment is presented
at section 8. As depicted at Figure 2.1, the MEOSAR ground segment will be comprised of
Cospas-Sarsat MCCs, MEOLUTs and possibly ground control stations for return link
functions. The specification for Cospas-Sarsat MCCs is provided in Cospas-Sarsat System
document C/S A.005. Changes to these requirements may be needed to address specific
characteristics of the MEOSAR system.
The technical requirements for a Cospas-Sarsat MEOLUT will be developed during the
definition and development phase of the DASS, SAR/Galileo and SAR/Glonass programmes.
From a programmatic perspective, the provision of MEOLUTs will be an individual national
responsibility. MEOSAR satellite providers will make their satellite downlinks available
internationally for processing by MEOLUTs operated by Cospas-Sarsat Ground Segment
Operators. However, MEOSAR providers will not be responsible for providing all the
MEOLUTs necessary to support global coverage. Noting that the four MEOSAR
constellations are expected to be interoperable as defined in section 3, it is envisaged that
MEOLUTs will have the capability to receive and process the downlinks of all four MEOSAR
satellite constellations.
2-4
Depending on the decisions taken in respect of providing the advanced SAR services (sections
2.6 and 7 refer), there may also be a requirement for MEOSAR providers to develop and install
ground facilities to implement these additional functions.
2.4
MEOSAR Link Budget
The performance of the MEOSAR system and, therefore, the overall design of the MEOSAR
space and ground segment are strongly affected by the beacon to satellite to MEOLUT link
budget. A sample MEOSAR single path link budget depicting a nominal case situation is
provided at Annex J. In order to assess the anticipated performance of the DASS, SAR/BDS,
SAR/Galileo and SAR/Glonass components, typical link budgets are required for each.
Action Item 2.1: MEOSAR providers should develop link budgets for their respective
MEOSAR satellite constellations for inclusion in future revisions of this document. The link
budgets should conform to the assumptions and format adopted for the sample link budget
provided at Annex J.
2.5
MEOSAR 406 MHz Beacon Location Accuracy and Responsiveness
The MEOSAR system will provide independent distress beacon location information using a
combination of Time Difference of Arrival (TDOA) and Frequency Difference of Arrival
(FDOA) techniques. MEOLUTs calculate the beacon location by measuring and processing
the time and frequency differences of the same beacon burst relayed by different satellites. In
theory, a minimum of two simultaneous satellite receptions is required for MEOLUTs to locate
beacons using TDOA/FDOA techniques (document EWG-1/2002/3/2). However, current
performance evaluations are based on a minimum of 3 satellites relaying each beacon burst.
MEOSAR location accuracy is affected by many factors including the number of time and
frequency measurements available at the MEOLUT for a particular beacon burst, the accuracy
of the time and frequency measurements, and the geometry between the beacon and the
satellites.
The time required for a MEOSAR system to produce independent location information is also
affected by several factors, the most significant being the length of time required for multiple
satellites to provide simultaneous visibility of the beacon and a MEOLUT. A more thorough
description of the MEOSAR independent location capability and the various factors that impact
upon location performance is provided at section 5.
Because the MEOSAR system will be completely compatible with all Cospas-Sarsat 406 MHz
beacon message protocols, it will also provide location information available from the message
content of location protocol beacons. In such instances location information could be provided
without the need for TDOA/FDOA processing, and could be available even if only one satellite
provided simultaneous visibility of the beacon and the MEOLUT.
2-5
2.6
Advanced Capabilities
Since the MEOSAR system is being developed using new concepts, the opportunity exists to
incorporate additional functions and/or capabilities that might benefit SAR services. The
options being considered include:
• a return link to the beacon that might possibly be used to acknowledge reception of a
distress alert, and/or control beacon transmissions; and
• support for a new generation of 406 MHz beacons that might provide a superior link
budget, improved message content, and support more accurate time-tagging by
MEOLUTs.
A more detailed discussion of possible additional capabilities is provided at section 7.
2.7
DASS
2.7.1
DASS System Architecture
The DASS system will include:
• 406 MHz repeaters on all 24 satellites of the GPS system, plus the 3 satellites
designated as in-orbit spares; and
• Cospas-Sarsat MEOLUTs located throughout the world as required to provide
global coverage.
A decision has not been made regarding a DASS return link service as described in
section 2.6 above. If the decision is made to provide a return link, an additional ground
segment component would be required to provide and manage return link
transmissions.
GPS satellites orbit the Earth at altitudes of 20,182 km. The constellation of
24 satellites is distributed in 6 different orbital planes, equally spaced in longitude.
With this constellation every point on the Earth is visible by at least 4 satellites at all
times, with a minimum elevation angle of 5º.
2-6
2.7.2
DASS SAR Payload
The DASS SAR payload will include a transponder that will relay the signals
transmitted by 406 MHz distress beacons. The technical characteristics of the
transponders are provided at Annex B. Operational DASS transponders are expected
to use downlinks in the 1544 – 1545 MHz band; however, the proof of concept /
in-orbit validation phases of DASS implementation will be conducted using
transponders with S-band downlinks.
A decision has not yet been made concerning the use of return link services on DASS;
therefore, the associated payload requirements to implement this function are not
addressed in this document.
2.8
SAR/Galileo
2.8.1
SAR/Galileo System Architecture
The SAR/Galileo system will consist of:
• 406 MHz repeaters on TBD* satellites of the Galileo navigation system, plus the
TBC [3] satellites designated as in-orbit spares;
• Cospas-Sarsat MEOLUTs located throughout the world as required to provide
global coverage; and
• a Return Link Service Provider (RLSP) interfacing to the Galileo ground segment
for uploading return link messages to Galileo satellites.
Galileo satellites will orbit the Earth at an altitude of approximately 23,200 km. The
constellation of 27 satellites will be distributed in 3 planes equally spaced in longitude.
With this constellation every point on the Earth will be in visibility of at least 6
satellites at all times with a minimum elevation angle of 5º (document MEOSAR-
1/2004/Inf.2). As indicated at Figure 2.2, the SAR/Galileo return link function will
be integrated into the Galileo mission uplink, which will operate at C-band.
* Note: Subject to confirmation on the number of payloads needed to meet the Cospas-Sarsat
MEOSAR mission objectives.
2-7
Figure 2.2: SAR/Galileo System Concept
2.8.2
SAR/Galileo Payload
The SAR payload, depicted at Figure 2.3, consists of the forward link 406 MHz
receive antenna, transponder and a 1544 MHz transmit antenna, and a return link for
SAR-related acknowledgements and other messages. In terms of hardware, the return
link is part of the Galileo ground mission segment (GMS) and navigation payload.
The technical characteristics of the forward link transponder are provided at Annex C.
Figure 2.3: SAR/Galileo Payload Functions
SAR Transponder
Navigation Payload
406 MHz
1544 MHz
SAR Rx
Antenna
1544 MHz
Downlink Antenna
Navigation L-Band
Tx Antenna
C-Band Rx
Antenna
2-8
2.8.3
SAR/Galileo Return Link Functions
SAR/Galileo will provide the advanced services for SAR described at section 2.6.
The detailed operational and technical requirements for these functions have not yet
been defined.
2.9
SAR/Glonass
2.9.1 SAR/Glonass System Architecture
The SAR/Glonass system will consist of:
•
406 MHz repeaters on all satellites of the Glonass-K navigation system plus 6
satellites as in orbit spares; and
•
Cospas-Sarsat MEOLUTs located throughout the world as required to provide
global coverage.
Glonass satellites orbit the Earth at altitudes of 19,140 km. The constellation of
Glonass satellites is distributed in 3 different orbital planes, equally spaced in
longitude. With this constellation every point on the Earth is in visibility of at least
4 satellites with an elevation angle greater than 5 degrees at all times.
A decision has not yet been made regarding whether SAR/Glonass would also provide
a return link service to the beacon as described in section 2.6. If so, an additional
ground segment component would be required to provide and manage return link
transmissions.
2.9.2 SAR/Glonass SAR Payload
The SAR/Glonass payload will include a 406 MHz repeater to relay the signals
transmitted by 406 MHz distress beacons. A technical description of the SAR/Glonass
406 MHz transponder is provided at Annex D.
2.10
SAR/BeiDou
BeiDou Satellite Navigation System (BDS) will consist of three satellites in
geostationary orbit (GEO), 24 satellites in medium Earth orbit(MEO) and three
satellites in inclined geosynchronous satellite orbit (IGSO). China is planning to
install MEOSAR payloads compliant with Cospas-Sarsat technical standards aboard
BDS MEOSAR satellites, with a view to providing high accuracy distress alerting
2-9
service together with other MEOSAR satellite constellations SAR/GPS, SAR/Galileo,
and SAR/Glonass.
Annex R contains preliminary information on the BeiDou 406 MHz MEOSAR
repeater including repeater configuration, modes of operation and performance
characteristics.
Action Item 2.2:
MEOSAR providers should update, as necessary, the information
concerning the design, performance, and functionality of their system.
- END OF SECTION 2 -
3-1
3.
MEOSAR COMPATIBILITY AND INTEROPERABILITY
This section defines the concept of MEOSAR system compatibility with the existing Cospas-
Sarsat System that includes LEOSAR and GEOSAR components, and the concept of
“interoperability” of the four MEOSAR satellite constellations with Cospas-Sarsat MEOLUTs.
3.1
System Compatibility and Interoperability Concepts
As a minimum, the MEOSAR system must ensure compatibility with the existing Cospas-
Sarsat LEOSAR and GEOSAR systems, and also compatibility with each other, i.e. they should
not impact on the operation of the existing systems, or of other MEOSAR constellations that
might operate in the same frequency bands. In addition, a MEOSAR system must be able to
process 406 MHz beacons that meet Cospas-Sarsat requirements for operation in the LEOSAR
and GEOSAR systems.
Moreover, there are clear benefits to ensuring that Cospas-Sarsat MEOLUTs will be capable
of processing the downlink signals of all MEOSAR constellations.
The International Cospas-Sarsat Programme Agreement was established to ensure the
continuity of the international cooperation that resulted in the implementation of an
international satellite distress alerting system using a variety of space and ground segment
components. Although slight differences exist between the satellite payloads in the LEOSAR
system, they are basically interoperable, i.e. the same ground segment architecture allows for
a local user terminal (LUT) to track, receive and process data from both satellite series.
Similarly, although the performance characteristics of the various satellite payloads in the
GEOSAR system are different, GEOLUTs must satisfy a common set of performance criteria
that ensures consistent distress alerting performance. The advantages of interoperable systems
include:
a.
a robust ground segment providing redundancy and allowing quicker detection and
location of distress beacons;
b.
a more efficient management of the System that results from a consistent set of
performance requirements for the space and ground segment components;
c.
reduced costs of establishing LUTs through competition and economies of scale; and
d.
an encouragement for other States to contribute additional ground segment equipment to
the “joint” system, and consequently a reinforcement of the international acceptance of
the interoperable systems.
The same considerations apply to a MEOSAR system, and a basic objective of 406 MHz
MEOSAR providers is to ensure that as far as practical, all MEOSAR components are
interoperable with each other.
3-2
3.2
Definition of MEOSAR System Compatibility and Interoperability
3.2.1 Compatibility:
The MEOSAR system is capable of orderly and efficient integration and operation with
the Cospas-Sarsat System. The MEOSAR constellations are able to coexist on a non-
interfering basis with each other and with the existing Cospas-Sarsat System.
3.2.2 Interoperability:
The components of the MEOSAR system conform to a common architecture and
comply with agreed performance standards. A set of similar satellite downlink
characteristics allows MEOLUTs to track satellites and process signals from
interoperable MEOSAR constellations.
3.3
MEOSAR Compatibility and Interoperability Requirements
The Cospas-Sarsat requirements in respect of MEOSAR compatibility are addressed in
section 5, except for the detailed technical analysis concerning frequency coordination and
Cospas-Sarsat frequency protection requirements which are detailed in document C/S T.014.
The requirements for MEOSAR interoperability are addressed at section 6 (MEOSAR
payloads) and section 8 (MEOSAR Ground Segment).
- END OF SECTION 3 –
4-1
4.
PROGRAMME MANAGEMENT AND COORDINATION
This section describes the management structure and policies agreed by the Cospas-Sarsat
Council for coordinating the development and introduction of a 406 MHz MEOSAR system
into the operational Cospas-Sarsat System.
The principles that govern the management of the Cospas-Sarsat Programme and the
responsibilities of Participants for the provision and operation of ground and space segment
components of the Cospas-Sarsat System are defined in the International Cospas-Sarsat
Programme Agreement (ICSPA). Because Russia and the USA are Parties to the ICSPA, the
development and the integration of their MEOSAR satellite constellations into the Cospas-
Sarsat System can be accommodated within the framework established by the ICSPA, as an
enhancement to the existing Cospas-Sarsat System, and managed by the Cospas-Sarsat Council
through the existing management structure (i.e. Council, Joint Committee, Task Groups,
Experts Working Groups, etc.). However, because China and the EC/ESA are not parties to
the ICSPA, a specific management structure is required for coordinating the development and
integration activities for SAR/BDS and SAR/Galileo.
It is expected that a formal agreement between Cospas-Sarsat and the appropriate authority
responsible for the development of the SAR/BDS and SAR/Galileo systems would provide the
required management structure for the development and integration of SAR/BDS and
SAR/Galileo into the Cospas-Sarsat System.
4.1
Development and Integration of the MEOSAR System
Section 10 of this document describes the procedures agreed amongst Cospas-Sarsat Parties
and MEOSAR Providers for the development, proof of concept, demonstration and evaluation
phases of MEOSAR programmes, and the integration of an operational MEOSAR system into
the Cospas-Sarsat System. During the development, proof of concept, and the demonstration
and evaluation phases of the MEOSAR system (i.e. prior to the Council decision to accept the
MEOSAR system as an enhancement to Cospas-Sarsat in an initial operational capability),
significant changes to the management structure of the Cospas-Sarsat Programme should be
avoided, as the primary objective of the Council remains that of ensuring the continuous
availability of reliable, efficient and dependable satellite alerting capabilities based on the
LEOSAR and GEOSAR satellite systems, in accordance with the Parties’ commitments under
the ICSPA.
Therefore, during the development, demonstration and evaluation phases, the coordination
amongst MEOSAR Providers and Cospas-Sarsat Participants should be effected through the
Council, taking the opportunity of regular Cospas-Sarsat meetings or during special experts’
meetings established by the Council on an ad hoc basis.
However, as noted above, the organisations responsible for the management of SAR/BDS and
SAR/Galileo are not a Party to the ICSPA. Therefore, the Cospas-Sarsat Council would need
to enter into a specific agreement with the SAR/BDS and SAR/Galileo management
organisations that:
4-2
a.
identifies the organisations responsible for the development, testing and operation of
SAR/BDS and SAR/Galileo;
b.
delineates the authorities and scope of responsibilities of these organisations in respect
of the coordination of SAR/BDS and SAR/Galileo integration into the Cospas-Sarsat
system;
c.
defines the role, responsibilities, and authority of the Cospas-Sarsat Council and its
subsidiary organs (i.e. Joint Committee, Experts Working Groups, etc.) in respect of
the development and integration of SAR/BDS and SAR/Galileo into Cospas-Sarsat;
and
d.
defines the procedures for progressing operational, technical and management issues
that impact upon MEOSAR development and integration into the Cospas-Sarsat
System, including the documentation of decisions, recommendations and actions
agreed between Cospas-Sarsat and SAR/BDS, and between Cospas-Sarsat and
SAR/Galileo.
In addition, the MEOSAR Providers have stated that they do not intend to fund, procure and
operate the complete ground segment required to provide global coverage. Such a complete
ground segment providing global coverage will encompass a number of ground
receiving/processing stations (MEOLUTs) established world-wide.
Furthermore, as described in section 3 of this document, there are significant advantages to
establishing MEOLUTs that operate simultaneously with several MEOSAR satellite systems.
Since the development of such ground processing capabilities for MEOSAR distress alerting
will also have to be coordinated with Cospas-Sarsat, it would be advantageous to envisage that:
-
the development, testing and operation of MEOLUTs should be coordinated by
Cospas-Sarsat in the framework of the existing ICSPA;
-
a common set of performance requirements should be agreed by Cospas-Sarsat, taking
into account the design and capabilities of each MEOSAR constellation; and
-
all MEOLUTs would be required to undergo commissioning testing before being
authorised to input distress alert information into the Cospas-Sarsat System.
As is the case with the Cospas-Sarsat LEOSAR and GEOSAR systems, the formal process of
MEOLUT commissioning testing and reporting would be the responsibility of the respective
MEOLUT provider, and the Cospas-Sarsat Council would have final authority to approve the
commissioning of a MEOLUT into the Cospas-Sarsat System.
Annex H summarises the guidance provided above, and further details the work plan to be
undertaken during the development and integration of the MEOSAR system.
4.2
Institutional / Management Structure for the Operational MEOSAR System
Upon the completion of the MEOSAR development, proof of concept, demonstration and
evaluation phases, the MEOSAR system could become an essential component of the
operational Cospas-Sarsat System. However, in the absence of any operational experience of
4-3
the MEOSAR system’s performance, it would be premature to speculate on the long-term
impact of the introduction of an operational MEOSAR system on the existing LEOSAR and
GEOSAR components of Cospas-Sarsat.
The possible institutional evolution of the Cospas-Sarsat Programme and the future roles and
responsibilities of MEOSAR space segment and/or ground segment providers will have to be
considered in parallel with the development and implementation of MEOSAR capabilities. In
the future there will be a requirement to define a stable and comprehensive management
framework for the Cospas-Sarsat Programme that will ensure the continuity and availability of
406 MHz satellite alerting services to users worldwide, and address, as required, the provision
and operation of the MEOSAR system.
- END OF SECTION 4 -
5-1
5.
COSPAS-SARSAT REQUIREMENTS FOR A MEOSAR SYSTEM
5.1
Fundamental MEOSAR Requirements
The primary goal of the proposed MEOSAR system is to provide a reliable distress alerting
service for 406 MHz beacons that would enhance the services provided by Cospas-Sarsat
LEOSAR and GEOSAR systems. Furthermore, to be incorporated into the Cospas-Sarsat
System, MEOSAR system components should be provided and managed in accordance with
the principles that govern the Cospas-Sarsat Programme. These guiding principles impose the
following requirements.
a.
MEOSAR services should be provided free of charge to the end user in distress.
b.
the MEOSAR system should not generate harmful interference to the Cospas-Sarsat
LEOSAR and GEOSAR systems.
c.
the MEOSAR system should be completely compatible with Cospas-Sarsat 406 MHz
distress beacons.
d.
MEOSAR downlinks should be openly accessible and free of charge to Cospas-Sarsat
Ground Segment Providers worldwide.
e.
the MEOSAR system must achieve minimum performance levels agreed by the
Cospas-Sarsat Council.
5.2
Minimum MEOSAR Performance Levels for Cospas-Sarsat Compatibility
To study the feasibility of providing a MEOSAR capability, MEOSAR space segment
providers needed baseline performance requirements against which different designs could be
evaluated. Furthermore, Cospas-Sarsat was sensitive to the view that, prior to making the
significant investment needed to develop their contributions, MEOSAR providers would need
a mechanism and criteria for assessing whether their planned contributions would be
compatible with, and would enhance, the Cospas-Sarsat System.
In response to the above, Cospas-Sarsat established, in cooperation with the MEOSAR
providers, minimum MEOSAR system performance requirements for compatibility with the
Cospas-Sarsat System. These minimum requirements, provided at Annex E, duplicate the key
performance levels provided by the Cospas-Sarsat LEOSAR and GEOSAR systems.
The reason for basing minimum MEOSAR requirements on existing Cospas-Sarsat
performance levels is that, although a MEOSAR system will have the potential to provide
superior performance in many aspects, insufficient information is available at this stage to
define specific performance levels that could be achieved practically. However, if the
MEOSAR system replicated current LEOSAR and GEOSAR performance, it would benefit the
System, and, therefore, should be accepted as part of Cospas-Sarsat.
5-2
5.3
Enhanced MEOSAR Performance Objectives
Because of the coverage provided by MEOSAR satellites and the number of satellites in each
MEOSAR constellation, the MEOSAR system has the potential to provide performance that
exceeds the minimum requirements established above. Cospas-Sarsat and MEOSAR providers
agreed that MEOSAR performance should not be limited to those defined for Cospas-Sarsat
compatibility, rather, every effort should be made to develop a system that provides the
maximum benefits to SAR services. The following sections summarise analyses in respect of
achievable MEOSAR performance in key areas.
Action Item 5.1:
MEOSAR providers are invited to conduct analysis to identify
performance levels that can be achieved practically. The analysis should particularly
investigate the beacon to satellite and satellite to MEOLUT link budgets, and their impact on
various aspects of overall MEOSAR system performance.
5.3.1
Detection Probability
The Cospas-Sarsat LEOSAR system has less than full-Earth visibility at any time due
to the limited number of satellites on orbit. Beacons outside a satellite's coverage area
can therefore not be immediately detected, but must continue to transmit until a
satellite passes overhead. GEOSAR satellites, though visible nearly everywhere in the
Earth's mid-latitude regions, can be blocked from a beacon's view by terrain features.
MEOSAR systems, due to their large numbers of satellites, changing orbital positions
and large fields of view, can significantly reduce or eliminate these limitations and can
increase a beacon's probability of detection.
5.3.2
Independent Location Probability
TBD
5.3.3
Independent Location Accuracy
Unlike the Cospas-Sarsat LEOSAR system, which produces independent Doppler
locations from a single pass of a single satellite, MEOSAR beacon location algorithms
require the beacon transmission to be simultaneously repeated by multiple satellites.
The MEOSAR independent location determination performance is affected by the
geometry of the satellites in visibility of the beacon, and the number of satellites that
simultaneously repeat the beacon transmission.
Preliminary studies conducted by the USA (EWG-1/2002/3/2) concluded that a
complete DASS constellation would provide instantaneous visibility by at least
3 satellites anywhere on the surface of the Earth. Furthermore, assuming a suitable
ground segment, DASS would provide independent location information from a single
406 MHz beacon burst accurate to within 6.1 km 95% of the time. In addition,
subsequent beacon transmissions could be used to refine the location and an accuracy
of 1 km could be achievable within [TBD] minutes after a beacon started transmitting.
Action Item 5.2:
MEOSAR providers are invited to conduct analysis to identify anticipated
MEOSAR location determination performance in respect of location accuracy and time to
5-3
produce location information, and to propose options for optimising MEOSAR location
determination performance.
5.3.4
Error Ellipse
TBD
5.3.5
Sensitivity
TBD
5.3.6
Availability
A study conducted by the USA assessing the impact of satellite failures concluded that
a MEOSAR system would continue to perform well even if the constellations became
reduced. The analysis showed that, assuming only DASS satellites in orbit and with
the highly unlikely loss of six satellites randomly selected from a nominal
constellation, beacons would still have immediate visibility to 3 or more DASS
satellites 99.5% of the time, and the independent location capability would still be
provided with only a minor reduction in accuracy.
The availability of MEOSAR services would be further enhanced for a MEOSAR
system comprised of satellite constellations fully interoperable with all Cospas-Sarsat
MEOLUTs. Table 5.1 provides the expected performance for different availability
scenarios of DASS and SAR/Galileo satellite constellations, assuming a global ground
segment of MEOLUTs capable of processing both constellations.
Table 5.1 - Performance of Combined DASS and SAR/Galileo Constellations
Combined DASS - SAR/Galileo Scenario
Immediate 3
Satellite Visibility
(%)
Single Burst
Location Accuracy
(95th percentile)
24 Randomly Selected DASS - SAR/Galileo Satellites
99.8
7.4 km
48 Randomly Selected DASS - SAR/Galileo Satellites
4.1 km
5-4
5.3.7
Coverage
The MEOSAR requirement for global coverage duplicates the performance of the
Cospas-Sarsat LEOSAR system, which provides complete global coverage (including
the polar regions) for 406 MHz distress beacons. The LEOSAR system achieves this
performance using satellite on-board processing of beacon messages and data storage.
In effect, because of the onboard memory the LEOSAR system could provide global
coverage with a single satellite and a single LEOLUT, but with excessive delay.
The coverage provided by the MEOSAR system will be determined by the availability
of a suitable MEOLUT ground segment. The coverage provided with a single
MEOLUT is dependent upon the minimum number of satellites that need to achieve
simultaneous visibility of both the beacon and the MEOLUT to allow for independent
location determination with the required accuracy. Figure 5.1 depicts the nominal
coverage for a stand-alone MEOLUT tracking SAR/Galileo satellites.
To achieve global coverage as soon as possible, MEOSAR providers are investigating
various possibilities for ground segment architecture and MEOLUT design, including:
•
networking MEOLUTs to enable them to share beacon burst time and frequency
measurement data with each other; and
•
the space and ground segment requirements necessary for Cospas-Sarsat
MEOLUTs to receive and process the downlink signals from all MEOSAR
satellite constellations.
Figure 5.1: Coverage Area of a Single Stand-alone MEOLUT
(non-networked MEOLUT)
The contours depicted in Figure 5.1 show continuous coverage by at least
“N” satellites with mutual visibility of the beacon and the MEOLUT. The edge of
coverage limits depicted in the figure correspond to 5º beacon-to-satellite and
15º MEOLUT-to-satellite elevation angles.
5-5
5.3.8
Capacity
The MEOSAR capacity requirement to support a population of more than 3.8 million
beacons is based upon the projected beacon population growth and the channel
assignment strategy adopted by Cospas-Sarsat for optimising the capacity of the
LEOSAR and GEOSAR systems.
Because a MEOSAR system requires multiple simultaneous beacon, satellite and
MEOLUT visibility, the model for calculating MEOSAR capacity is likely to be
different from either the LEOSAR or GEOSAR system models. Furthermore, in light
of the relationship between capacity and channel assignment strategies, an optimum
channel assignment strategy that would accommodate LEOSAR, GEOSAR and
MEOSAR systems is needed.
System capacity is defined as the number of 406 MHz distress beacons operating
simultaneously that can be successfully processed to provide a beacon geolocation,
under nominal conditions. As the number of simultaneous beacon transmissions
increases, so does the incidence of interfering collisions between transmitted signals.
Such collisions tend to increase the time required for the system to locate a beacon.
To minimize the incidence of interfering collisions between transmitted signals and to
improve system capacity, the 406-406.1 MHz band has been divided into
approximately twenty-five 3 KHz channels in which Cospas-Sarsat attempts to control
the number of beacons operating in each channel.
Preliminary capacity studies indicate that the MEOSAR system will provide a large
capacity that will adequately support the projected beacon population growth.
Action Item 5.3:
MEOSAR providers and Cospas-Sarsat are invited to develop a MEOSAR
capacity model, and proposals for a 406 MHz channel assignment strategy that accommodates
LEOSAR, GEOSAR and MEOSAR requirements.
5.3.9
Interferer Processing
Studies conducted by the USA indicate that a MEOSAR system should be able to
locate 406 MHz interfering emitters using the same general techniques used to locate
distress beacons. Preliminary analyses indicate that it should be possible to
automatically locate narrow band signals to accuracies similar to beacons. However,
it may be necessary to store and use off-line techniques for locating wide band signals
(EWG-1/2002/3/1).
The impact of possible interference to a MEOSAR system from wind profiler radars
operating near the 406 MHz band will have to be considered. The adverse impact of
these radars to the Cospas-Sarsat LEOSAR system has been addressed by turning the
radars off when LEOSAR satellites are overhead. The radars do not affect the
GEOSAR systems because GEOLUTs use directional antennas that are always pointed
at a single stationary satellite, therefore, they are not impacted by the highly directional
transmissions from wind profiler radars. Because of the number of MEOSAR
satellites and their orbital positions, the scheduling techniques adopted for the
LEOSAR system will not be possible with a complete MEOSAR constellation.
5-6
Action Item 5.4:
Cospas-Sarsat Participants are invited to:
a.
investigate whether their respective Administrations operate, or have knowledge of
other Administrations which operate wind profiler radars at 404.3 MHz, and report
their findings to the Council; and
b.
request administrations operating wind profilers at 404.3 MHz to move these radars
to the 449 MHz frequency band by the year 2005.
5.3.10
Processing Anomalies
TBD
5.4
Evaluation of MEOSAR Performance
Evaluation of MEOSAR system performance will be made during the demonstration and
evaluation (D&E) phase (see section 10 for a description of the scope of the D&E). However,
the actual MEOSAR performance will depend upon the availability of complete space and
ground segments, which may or may not be in place at the time of the D&E.
The decision to use alerts produced by the MEOSAR system operationally will be dependant
upon the performance demonstrated during the D&E. Complete MEOSAR ground and space
segments will not be a prerequisite for deciding whether MEOSAR alerts should be distributed
within the Cospas-Sarsat Ground Segment, instead the Council will take this decision based
upon their assessment of whether distress alerts from an incomplete MEOSAR system would
enhance the existing Cospas-Sarsat distress alerting service.
- END OF SECTION 5 -
6-1
6.
MEOSAR PAYLOADS
This section describes requirements for ensuring that MEOSAR payloads will not generate
harmful interference to other systems, and payload requirements for achieving full DASS,
SAR/BDS, SAR/Galileo and SAR/Glonass interoperability.
6.1
MEOSAR Downlinks
The DASS, SAR/BDS, SAR/BDS, SAR/Galileo, and SAR/Glonass MEOSAR constellations
plan to operate with satellite downlinks in the 1544 – 1545 MHz band. The ITU Radio
Regulations allocate the 1544 – 1545 MHz band to the mobile satellite service (MSS), space-
to-earth, for distress and safety communications (article 5.356). International agreement to
operate systems in this band is achieved by completing the formal frequency coordination
process with other administrations that have successfully notified their use of the band to the
ITU. This process, which establishes whether proposed new systems would generate harmful
interference to other “notified” systems, will have to be completed for each MEOSAR satellite
constellation. In effect MEOSAR providers will need to design downlinks that support SAR
performance requirements, whilst:
a.
not generating harmful interference to other authorised users of the band or to other
MEOSAR components; and
b.
operating in the presence of emissions from the other systems authorised to operate in
the band.
Tables 6.1 through 6.4 below summarise the preliminary information provided by the USA,
China, EC/ESA and Russia concerning their respective plans for the DASS, SAR/BDS,
SAR/Galileo and SAR/Glonass MEOSAR downlinks.
The preliminary plan for MEOSAR system use of the 1544 – 1545 MHz band is depicted at
Figure 6.1. This plan cannot be finalised until the protection requirements for the other users
of the band have been established, the level of interference in the band from existing users has
been quantified, and detailed analysis has been conducted to evaluate each proposed MEOSAR
component against these criteria.
Table 6.1 - DASS Payload Downlink Characteristics
DASS Payload Downlink Characteristics
Item
Description
Payload type
Direct frequency translation repeater
Downlink frequency
Occupies 200 kHz from 1544.8 to 1545.0 MHz
Downlink EIRP
17.5 dBW
Downlink polarisation
Right Hand Circular Polarisation (RHCP)
Bandwidth relayed
406.0 – 406.1 MHz, possibly reduced by small amount to accommodate MEOSAR
Doppler shift
6-2
Table 6.2 - SAR/Galileo Payload Downlink Characteristics
SAR/Galileo Payload Downlink Characteristics
Item
Description
Payload type
Direct frequency translation repeater
Downlink frequency\*
Occupies 100 kHz from 1544.0 to 1544.2 MHz
Downlink EIRP
>16.8 dBW over the entire Earth coverage
Downlink polarisation
Left Hand Circular Polarisation (LHCP)
Bandwidth relayed
406.005 – 406.095 MHz (1 dB bandwidth)
Table 6.3 - SAR/Glonass Payload Downlink Characteristics
SAR/Glonass Payload Downlink Characteristics
Item
Description
Payload type
Direct frequency translation repeater
Downlink frequency**
Occupies approximately 100 kHz between 1544.8 and 1545.0 MHz
Downlink EIRP
19.0 dBW
Downlink polarisation
Left Hand Circular Polarisation (LHCP)
Bandwidth relayed
406.0 – 406.1 MHz, possibly reduced by small amount to accommodate MEOSAR
Doppler shift
Table 6.4 - SAR/BDS Payload Downlink Characteristics
SAR/BDS Payload Downlink Characteristics
Item
Description
Payload type
Direct frequency translation repeater
Downlink frequency
Occupies approximately 100 kHz from [ 1544.16 to 1544.26 MHz]
Downlink EIRP
18.0 dBW
Downlink polarisation
[Right Hand Circular Polarisation (RHCP)]
Bandwidth relayed
406.01 – 406.09 MHz (1 dB bandwidth)
Figure 6.1: 1544 – 1545 MHz Band Plan
Notes: * SAR/Galileo will occupy approximately 100 kHz in the 1544.0 – 1544.2 MHz band.
** Exact Location of SAR/Glonass downlink has yet to be determined.
1544.0
1544.1
1544.2
1544.3
1544.4
1544.5
1544.6
1544.7
1544.8
1544.9
1545.0
Frequency (MHz)
Cospas-Sarsat LEOSAR
GOES, MSG and
Electro-L
GEOSAR
SAR/Galileo\*
SAR/GPS
**SAR/
Glonass
SAR/
BDS
6-3
6.2
MEOSAR Interference to Existing Users
The systems listed below have been notified, or are in the process of being notified, to the ITU
to operate in the 1544 – 1545 MHz band:
a.
Sarsat LEOSAR system;
b.
Cospas LEOSAR system;
c.
GOES GEOSAR;
d.
MSG GEOSAR;
e.
Electro-L GEOSAR
The protection requirements for some of the components of the Cospas-Sarsat systems above
are described in the draft Cospas-Sarsat System document C/S T.014 (Cospas-Sarsat frequency
protection and coordination requirements). A susceptibility mask for the 1544 – 1545 MHz
band based on the information currently available is provided at Figure 6.2.
Figure 6.2: Cospas-Sarsat LEOSAR and GEOSAR Susceptibility
Mask for 1544 – 1545 MHz Band
1544.0
1544.1
1544.2
1544.3
1544.4
1544.5
1544.6
1544.7
1544.8
1544.9
1545.0
Частота (MГц)
Спектральная плотность мощности
на наземной станции (dBW/m2Hz)
-206.2 dBW/m2Hz от
1544.2 до 1544.8 MГц
-220.5 dBW/m2Hz от
1544.40 до 1544.60 MГц
6-4
Action Item 6.1:
MEOSAR providers should:
a.
consider the protection requirements for the other systems that have notified their use
of the 1544 – 1545 MHz band when designing their MEOSAR downlinks;
b.
conduct investigations to identify other systems that have, or will have, started the
coordination / notification process with the ITU prior to the respective MEOSAR
provider, and consider the protection requirements for such systems when designing
MEOSAR downlinks; and
c.
initiate the formal ITU advance publication, coordination and notification process for
their MEOSAR satellite network, in accordance with the procedures described in the
Radio Regulations.
6.3
Interference to MEOSAR Downlinks
In addition to ensuring that the MEOSAR system does not cause interference to other systems,
the minimum MEOSAR system performance levels required for compatibility with Cospas-
Sarsat must be maintained while operating in the presence of emissions from systems in the
1544 – 1545 MHz band, as well as from other systems operating in adjacent frequency bands.
Specifically, each component of the MEOSAR system must be designed to account for possible
emissions in the MEOSAR downlink bands from:
•
MEOSAR satellites that operate with downlinks in the band;
•
Cospas-Sarsat LEOSAR and GEOSAR satellites;
•
other authorised systems using the 1544 – 1545 MHz band; and
•
out-of-band emissions from systems operating in adjacent bands.
The level of interference in the MEOSAR downlink band(s) impacts the overall design of a
MEOSAR system, and will require trade-offs between payload and MEOLUT design. For
example, the impact of interference could be mitigated by using more powerful MEOSAR
downlinks. This approach would add to the cost / complexity of the payload and possibly
increase the out-of-band emissions. Conversely, interference might be mitigated at the
MEOLUT by using more directional antennas and / or more sophisticated signal processing.
However, this would impact on MEOLUT cost and complexity.
In view of the above, design decisions taken to mitigate the impact of interference should be
considered at a MEOSAR system level taking into account the constraints imposed by both the
ground and space segments.
6-5
6.3.1 Mutual MEOSAR Interference
Preliminary analysis conducted by ESA (EWG-4/2002/4/2) concluded that it would be
feasible for two MEOSAR satellite constellations employing direct frequency
translation repeaters to operate without generating harmful interference to each other,
if one operates with downlinks in the lower portion of the band between 1544.0 and
1544.2 MHz and the other operates downlinks in the upper portion between 1544.8 and
1545.0 MHz.
With respect to the introduction of a third MEOSAR satellite constellation also
employing direct frequency translation repeaters, there is insufficient spectrum
available either in the upper or lower portion of the band to assign the third constellation
its own allocation.
However, as depicted at Figure 6.1 it might be feasible for DASS and SAR/Glonass to
share a portion of the available spectrum between 1544.8 and 1545.0 MHz for their
downlinks. In which case the DASS and SAR/Glonass systems could be designed to
be viewed by MEOLUTs as a single larger satellite constellation. This might provide
MEOLUTs with additional options for selecting satellites, thereby optimising
MEOSAR coverage and location determination performance. Additional analysis is
required to establish how many DASS and SAR/Glonass MEOSAR satellites can share
the upper portion of the band without generating harmful interference to each other. If
mutual MEOSAR interference became a problem, it might be necessary to turn-off
some DASS and SAR/Glonass MEOSAR payloads, in effect making them in-orbit
spares.
Since the primary role for all the satellites under consideration are the navigation
missions, replacement satellites might not be launched for the sole purpose of restoring
the constellation of MEOSAR payloads. Consequently, the availability of in-orbit
spares would be highly beneficial. If such an approach were adopted, a process for
determining which MEOSAR payloads would be turned-off will be required.
Action Item 6.2:
MEOSAR providers should study the issue of how many DASS and
SAR/Glonass MEOSAR repeaters could be accommodated in the upper portion of the band
without generating harmful interference to each other.
6.3.2 Interference to the MEOSAR System from LEOSAR Satellites
Although the useful signal from Sarsat LEOSAR downlinks is contained within the
1544.5 300 MHz band, Sarsat LEOSAR satellites transmit energy beyond this range,
into the bands being considered for MEOSAR downlinks. The worst-case spurious
emission limits from Sarsat repeaters is provided in Figure 3.12 of document C/S T.003
(LEOSAR payload description).
6-6
6.3.3 Interference to MEOSAR System from GEOSAR Satellites
Similar to the LEOSAR situation described above, the GOES, MSG and Electro-L
GEOSAR systems also transmit energy into the bands being considered for MEOSAR
downlinks. Spectrum plots for the GOES and MSG downlinks are provided in
document C/S T.011 (GEOSAR payload description).
6.3.4 Interference to MEOSAR System Downlinks from Other Systems
In addition to the LEOSAR and GEOSAR systems operated by Cospas-Sarsat, the
MEOSAR system must also be designed to accommodate downlink interference
originating from other systems operating within the 1544 – 1545 MHz band and
interference spilling over from systems operating outside the 1544 – 1545 MHz band.
In consideration of the Koreasat system, a detailed description of its transmissions in
the band was requested from the Korean Administration. However, a letter from the
Korean Director of Frequency Division and Radio & Broadcasting Bureau advised that
Koreasat was still in the planning stages and detailed information could not yet be
provided.
A USA study (EWG-2/2003/4/12-Rev.1) that quantified possible interference in the
1544 – 1545 MHz band from geostationary satellites in the Mobile Satellite Service
based upon information provided in filings with the ITU, indicated that the interference
levels could exceed the Cospas-Sarsat susceptibility mask provided at Figure 6.2.
However, the interference levels presented in the USA study represent the most
pessimistic case, since a large number of the systems filed with the ITU will likely never
become operational, and for those that do, many will utilise lower EIRP than advertised
for their downlinks. Additionally, the study did not consider that beacon signals will be
relayed by multiple satellites and will be received by multiple MEOLUTs at different
locations. Therefore, even if one MEOLUT is degraded by out-of-band interference,
the other MEOLUTs might remain unaffected and the overall system performance
impact will be minimal.
Action Item 6.3:
The Secretariat should forward any information regarding Koreasat
downlink provided by Korea to the MEOSAR providers.
Action Item 6.4:
MEOSAR providers should:
a.
establish susceptibility / protection requirements for their MEOSAR downlinks; and
b.
consider the possible interference from other systems, including inter MEOSAR satellite
constellation interference, when designing their downlinks, and confirm whether the
minimum performance required for compatibility with Cospas-Sarsat would still be
satisfied while operating in the presence of interference from these systems.
6-7
6.4
Payload Characteristics for MEOSAR Constellations Interoperability
Cospas-Sarsat and MEOSAR providers have agreed that it was highly desirable for MEOLUTs
to have the capability to receive and process the downlink signals from multiple MEOSAR
satellite constellations. Such a capability would provide options for selecting the optimum
satellites for a given coverage, and would enhance MEOSAR system redundancy.
In evaluating payload requirements for interoperability MEOSAR providers considered the
impact upon satellite complexity and cost, the available resources on the satellite (e.g. weight
and power), MEOSAR performance requirements for compatibility with Cospas-Sarsat, and
the impact that payload designs would have on MEOLUT cost and complexity. Based upon
these considerations MEOSAR providers and Cospas-Sarsat agreed the MEOSAR payload
characteristics for interoperability provided at Annex F.
The most significant payload characteristics that impact upon MEOSAR interoperability are:
• modulation of the downlinks;
• repeater bandwidth;
• downlink frequency;
• repeater receiver G/T;
• downlink EIRP;
• repeater dynamic range;
• downlink polarisation;
• repeater linearity; and
• group delay.
6.4.1 Modulation of the Downlink Signal
The decision by the USA, Russia, and the EC/ESA to use direct frequency translation
repeaters for their MEOSAR satellite payloads simplifies the development of
MEOLUTs capable of receiving and processing the signals from all MEOSAR
constellations.
6.4.2 Downlink Frequency
MEOSAR satellite constellations need not have the exact same downlink frequencies to
enable MEOLUTs to process their downlinks. Analysis conducted by ESA
(EWG-4/2002/4/1) concluded that it might be preferable to maintain some frequency
diversity since this would increase the robustness of the whole system. However, it is
important that the downlink frequencies be close enough to each other to minimise the
cost of MEOLUT receivers.
The frequency separation resulting from the DASS and SAR/Glonass MEOSAR
repeater downlinks operating in the upper portion, and the SAR/BDS (TBC) and
SAR/Galileo downlinks in the lower portion of the 1544 – 1545 MHz band will not
impede the development of MEOLUTs capable of receiving and processing the repeater
downlinks from the four MEOSAR satellite constellations.
6-8
6.4.3 MEOSAR Downlink EIRP
Analysis conducted by ESA regarding the impact of MEOSAR downlink power
(EWG-4/2002/4/1) concluded that the power spectral density received by MEOLUTs
directly impacts upon Time of Arrival (TOA) measurement accuracy and, therefore,
MEOSAR location accuracy. In addition the value of the MEOSAR downlink EIRP
drives requirements in respect of MEOLUT antenna options.
MEOSAR providers agreed that to ensure interoperability, MEOSAR downlink EIRPs
should exceed 15 dBW for all MEOLUT to satellite elevation angles above 5.
6.4.4 Downlink Polarisation
The selection of a downlink polarisation should take into consideration:
a.
the protection requirements for Cospas-Sarsat LEOSAR and GEOSAR systems;
b. the possible impact on MEOSAR system interoperability; and
c.
constraints imposed by the primary navigation mission.
Since the LEOSAR and GEOSAR systems have downlinks with opposite circular
polarisation, it is not possible to select a MEOSAR downlink polarisation that optimises
protection to both the LEOSAR and GEOSAR systems.
From the perspective of MEOSAR interoperability, adopting a common downlink
polarisation for all MEOSAR space segments would simplify the design of Cospas-
Sarsat MEOLUTs. However, having different downlink polarisations could be
accommodated in MEOLUT designs without imposing substantive additional
requirements.
Finally, the SAR mission is a secondary mission accommodated on satellites that are
supporting a primary navigation mission. The constraints imposed by the navigation
mission may guide the decision in respect of the MEOSAR downlink polarisation. For
example, since the MEOSAR downlink antenna may also be used by the navigation
payload, the decision on its polarisation may be dictated by the navigation payload
requirements.
The preliminary design for BDS and DASS is to operate with RHCP downlinks,
whereas SAR/Galileo and SAR/Glonass plan to operate LHCP downlinks.
6.4.5 Repeater Bandwidth
Ideally MEOSAR payloads should be capable of relaying the entire 406.0 – 406.1 MHz
bandwidth allocated by the ITU for 406 MHz distress beacons, whilst not relaying any
out-of-band signals. This would provide Cospas-Sarsat the greatest flexibility for
opening 406 MHz channels and maximise MEOSAR system capacity. However, in
practice MEOSAR payload bandwidth must take into account:
6-9
a.
the possible interference from other Systems operating in the adjacent bands,
which could be received in the 406.0 – 406.1 MHz band due to the combined
effect of Doppler and inadequate transmitter filtering characteristics; and
b.
the practical limitations of MEOSAR payload 406 MHz filter characteristics.
In view of the above, MEOSAR providers and Cospas-Sarsat agreed that the 406 MHz
10 dB pass-band must be less than 100 kHz, centred at 406.05 MHz, and that the 1 dB
pass-band must exceed 90 kHz.
6.4.6 Repeater Receiver G/T
Analysis conducted by France (MEOSAR-1/2004/5/3) concluded that, assuming
practical satellite receiver and receive antenna performance characteristics, the overall
MEOSAR link budget was 5 times more susceptible to degradations in the uplink than
the downlink. In view of this, the satellite receiver subsystem G/T is a critical
characteristic for both MEOSAR performance and interoperability.
MEOSAR providers and Cospas-Sarsat agreed that a repeater G/T value of -17.7 dB/K
or greater would enable the development of a fully interoperable MEOSAR system that
satisfied the performance requirements for compatibility with Cospas-Sarsat.
6.4.7
System Dynamic Range and Automatic Gain Control (AGC)
Characteristics
The repeater dynamic range and AGC characteristics determine the MEOSAR system’s
ability to adequately accommodate interference and varying beacon message traffic
loads. MEOSAR providers agreed that the repeater instantaneous linear range (not
including AGC) should meet or exceed 30 dB, and that the ratio of power from a relayed
beacon to intermodulation products should be greater than 30 dB when the repeater is
operating beyond its linear range.
To accommodate possible interference in the 406 MHz band all repeaters should include
an AGC mode with a range of at least 30 dB. Additional study is required to identify
suitable AGC attack time and decay time specifications, and to determine whether AGC
attack and delay time values must be standardised for interoperability.
6.4.8 Group Delay
Repeater group delay characteristics impact upon MEOLUT time-tagging accuracy and,
consequently, MEOSAR independent location accuracy performance. To ensure that
minimum performance requirements are satisfied regardless of the satellite
constellation relaying the beacon signal, MEOSAR providers agreed that repeater group
delay should be less than 10 S with a stability within that range of 500 nanoseconds.
6-10
6.4.9 Compatibility of Preliminary MEOSAR Payload Designs
The feasibility of operating one, two, three or four of the planned MEOSAR
constellations with downlinks in the 1544 – 1545 MHz band cannot be assessed reliably
until the characteristics of each MEOSAR payload have been established, and analysis
has been conducted to determine expected MEOSAR performance and the impact each
MEOSAR satellite constellation would have upon the other authorised users of the
band.
Action Item 6.5:
MEOSAR providers should conduct analyses for inclusion in future
revisions of this document, to refine the MEOSAR payload requirements provided at Annex F
for enabling MEOLUTs to receive and process the downlink signals from multiple MEOSAR
satellite constellations.
- END OF SECTION 6 -
7-1
7.
ADVANCED MEOSAR SYSTEM CAPABILITIES
MEOSAR providers are investigating the feasibility of advanced capabilities that might enhance
the overall effectiveness of SAR operations. The additional capabilities being considered
include:
a.
a possible return link to the beacon that could be used to acknowledge reception of distress
alerts, and/or control beacon transmissions; and
b.
support for beacons with different transmission characteristics that could improve beacon
effectiveness and reduce beacon cost.
7.1
MEOSAR Return Link Service
The Galileo MEOSAR design includes a return link to 406 MHz beacons that can be used for
transmitting information to the beacon through the Galileo L1 signal. The Return Link Service
(RLS) is provided through a dedicated facility called the “Return Link Service Provider” (RLSP),
which acts as an interface between the Cospas-Sarsat System and the Galileo system, as
illustrated in Figure 7.1. The available data bits dedicated to SAR on the L1 signal are used to
broadcast Return Link Messages (RLM) to beacons allowing various services complementary to
the existing Forward Link Alert Service. These complementary services could consist of a
confirmation of reception of the alert or other applications such as a capability to remotely
activate a specific beacon.
A number of operational implications for SAR authorities and the Cospas-Sarsat System need to
be thoroughly assessed through trials and testing before the potential operational benefits of the
Return Link Service can be demonstrated.
Figure 7.1: Overview of the SAR/Galileo Return Link Service within
the Cospas-Sarsat System Architecture
Cospas-
Sarsat
RLS
Capable
Beacon
SPOC (RCC)
RLSP
Galileo
LEO / MEO / GEO
Sat. RLM Request in FLAM
MEO (Galileo) – RLM on L1
RL Services
7-2
7.1.1
Return Link Services
The EC has conducted a worldwide survey of the SAR community, including MCCs,
RCCs and beacon manufacturers, to consolidate the definition of the proposed Return
Link Service. Among the various functions which could be offered through the Return
Link, the acknowledgment service should be implemented as a priority.
The Return Link Service can be provided to compatible beacons irrespective of the
satellite system (LEO, GEO or MEO) which provided the forward link 406 MHz alert.
7.1.1.1
Acknowledgment Service
An acknowledgment service through the Return Link can provide to the person(s) in
distress a confirmation of the detection of the alert and of the determination of its
location by the System, and possibly a further confirmation that the rescue operation is
underway. To enable this function, the beacon must transmit in the Forward Link Alert
Message1 (FLAM) a Return Link Message Request indicating to the System that an
acknowledgment of the distress alert is requested.
From analysis of the Return Link survey responses, two types of acknowledgement have
been defined:
• Type 1 Acknowledgment (System Acknowledgment): the Galileo system
automatically transmits via the RLSP a Return Link Message to the emitting beacon
after the alert has been detected and located and the RLM request has been received.
This will allow a fast delivery of the RLM particularly in the MEOSAR environment.
• Type 2 Acknowledgment (RCC Acknowledgment): in this case the RLSP will send
the RLM to the emitting beacon only after it has received an authorization from the
responsible RCC. This acknowledgment will inform the user that the alert is being
processed by an RCC. This type of acknowledgment would not be immediate as
SAR authorities might need time to assess the distress situation and determine the
proper response.
The Type 1 Acknowledgment Service (System Acknowledgment) definition is
relatively straightforward since it has minimal impact on the Cospas-Sarsat System and
SAR operations.
The Type 2 Acknowledgment Service (RCC Acknowledgment), however, will require
further assessment of operational implications for SAR and for the person in distress,
which includes extensive trials to validate the potential benefits.
The issues that have to be considered include:
a.
the exact operational role of SPOCs and RCCs in the Return Link
Acknowledgment Service;
1 406 MHz beacon message uplinked to the satellite
7-3
b.
the impact of the implementation of the Return Link Service architecture on
Cospas-Sarsat MCCs, RCCs and SPOCs (e.g. changes to MCC standards,
modification of interfaces, etc.);
c.
the role of the SAR/Galileo MEOSAR provider in coordinating acknowledgement
transmissions and managing possible Return Link services (e.g. need for specific
database and service registration for RLS beacons);
d.
the role of Cospas-Sarsat in developing beacon specifications and type approval
requirements for 406 MHz beacons with a return link capability (i.e. should
Cospas-Sarsat involvement be limited to ensuring no adverse impact on the
406 MHz distress alerting function, or should requirements for RLS capable
beacons be part of Cospas-Sarsat specifications and standards); and
e.
the
benefits
and
drawbacks
of
Type 2
Acknowledgement
(RCC
Acknowledgment).
7.1.1.2
Other Possible Return Link Services
A return link to the beacon might also be used to control the transmissions of suitably
designed new generation 406 MHz beacons. Examples where such a capability might
be useful include:
a.
activating beacons on boats and aircraft that have been reported missing;
b.
turning off beacon transmissions when the SAR mission has been completed, but
where it was not possible or practical to recover and turn off the beacon manually;
and
c.
changing the repetition rate of the beacon transmissions after the alert has been
received and location established without ambiguity, with a view to saving battery
power or reducing the beacon message traffic load on the satellite system.
Action Item 7.1:
Cospas-Sarsat Participants should investigate, through trials where
possible, the operational benefits and drawbacks that may be associated with distress alert
acknowledgement services and return link services that control beacon transmissions.
Action Item 7.2:
Cospas-Sarsat Participants and MEOSAR providers should conduct
analysis to identify suitable options for operating and managing acknowledgement services.
Action Item 7.3:
Cospas-Sarsat Participants and MEOSAR providers should develop
technical proposals for acknowledgement services (including description of the required
downlink signals and 406 MHz beacon specification / type approval requirements).
7-4
7.1.2 Return Link Service Architecture
Figure 7.2 presents a general overview of the facilities contributing to the Return Link
Acknowledgment Service.
Figure 7.2: Facilities Contributing to the Return Link Acknowledgment Service
The Return Link Message requests originating from beacons and coded in the FLAM
will be received by all types of LUTs (LEO/MEO/GEO) and transmitted to the RLSP
through a dissemination mechanism based as much as possible on current Cospas-Sarsat
alert data distribution procedures.
In the Type 1 Acknowledgment scenario the RLSP sends a Return Link Message to the
beacon through the Galileo system after it has received the RLM request and a
confirmation of the beacon localisation.
In the Type 2 Acknowledgment scenario the RLM request is also disseminated to the
RCC/SPOC in charge of the rescue operation. The RLSP will send a Return Link
Message to the beacon only after it has received a request to do so from the RCC in
charge.
The role of Cospas-Sarsat in the Return Link Acknowledgment Service will be strictly
limited to the dissemination of the RLM request. The actual authorisation for sending
an RLM will be issued at the level of the RLSP for Type 1 acknowledgements
(automatic system acknowledgments) or by RCCs for Type 2 acknowledgements (RCC
acknowledgments).
Associated MCC for SAR Area
SPOC/RCC
FMCC
Galileo GMS
RLSP
Nodal MCCs
Nodal MCCs
Nodal MCCs
MCCs
MCCs
MCCs
406 MHz
Distress
Signals
1544 MHz
Distress Signals
Galileo Space Segment
Uplink with
Return Link Message
Navigation
Signal (L1)
with Return
Link
Message
Distress Alert
Return Link
Message and
Information Dissemination
LEOLUT
MEOLUT
GEOLUT
Cospas-Sarsat
System
National SAR Facilities
SAR Operation
Galileo System
Cospas-Sarsat
Space Segment
7-5
In the first implementation step, the interface between the Galileo system and the
Cospas-Sarsat System will be provided by the RLSP interfacing with the FMCC and the
Galileo Mission Segment. In a second step, the feasibility of a direct interface with other
nodal MCCs for redundancy purposes will be considered. The RCC-RLSP interface
could be implemented as a simple web interface accessed by RCCs.
7.2
Implementation of the SAR/GALILEO Return Link Service
7.2.1
General
The SAR/Galileo return link capability takes advantage of the fact that 406 MHz
beacons equipped with a Galileo navigation receiver will have a built-in capability to
receive the Galileo navigation signal. Therefore, short SAR messages included in the
Galileo navigation signal (Galileo Signal-In-Space) can be received by the beacon. The
cost of beacons with the return link capability should not be significantly higher than
the cost of existing beacons which already include a GNSS receiver.
The development of operational navigation receivers for Galileo is outside the scope of
the Galileo return link development. However, progress of this development will be
closely monitored as the availability of Galileo receivers is a prerequisite to the
availability of 406 MHz beacons with a Return Link Service capability. The
development of operational beacons with an RLS capability is supported by the EC
through the development of prototype RLS beacons.
During the In-Orbit Validation (IOV) Phase of the Galileo Programme, prototype
beacons using the Cospas-Sarsat test protocol will be used for the testing of the
SAR/Galileo RLS. The technical objective of the IOV in respect of the SAR/Galileo
RLS will be to validate the feasibility of the basic RLS function, i.e. answering a beacon
RLM request with an acknowledgement (Type 1 and Type 2). A number of emulators
will be used to simulate the role of the Cospas-Sarsat network in the Return Link Service
for the dissemination of RLM requests.
Prior to declaring the SAR/Galileo system at Full Operational Capability, operational
beacons will be tested in an operational environment. Part of the Cospas-Sarsat network
will be used to validate procedures for the transmission of RLM requests from Cospas-
Sarsat LUTs to the RLSP, as defined in section 7.2.6 of this document.
The following sections provide a description of the implementation of various segments
involved in the SAR/Galileo Return Link Service.
7.2.2
SAR/Galileo System
The space segment and Galileo Mission Segment of the operational Galileo system will
provide the SAR/Galileo RLS by broadcasting Return Link Messages to distress
beacons on the Galileo navigation signal (Signal-In-Space). Return Link Messages will
be forwarded to beacons through two Galileo satellites simultaneously. The format of
the transmission is presented in section 7.2.4 of this document.
7-6
7.2.2.1 SAR/Galileo Return Link Architecture for In-Orbit Validation
The SAR/Galileo Return Link architecture for In-Orbit Validation (IOV) is illustrated
in Figure 7.3. In this architecture, the European prototype MEOLUT installed at the
Toulouse Space Centre will be used to receive test messages from RLS beacons. The
Cospas-Sarsat Ground Segment network will be replaced by the Cospas-Sarsat Network
Emulator (CSNE) to emulate the functions of the Cospas-Sarsat Ground Segment
contributing to the RLS implementation and forward RLM requests to the experimental
RLSP, also installed in Toulouse. Eventually the CSNE will be replaced by the FMCC
for preliminary testing of the dissemination procedure for RLM requests.
Figure 7.3: Galileo Return Link Service In-Orbit Validation Concept
7.2.2.2 Operational SAR/Galileo Return Link Architecture
The SAR/Galileo Return Link architecture envisaged for the system’s Full Operational
Capability (FOC) is presented in section 7.1.2 above. For the full implementation of a
global SAR/Galileo RLS, the Forward Link Alert Messages (FLAMs) received by any
of the Cospas-Sarsat LUTs (MEO, GEO and LEO) have to be analysed and the RLM
requests have to be identified and forwarded to the SAR/Galileo RLSP.
The first definition of this dissemination procedure is presented at section 7.2.6 and will
be further refined prior to its full operational implementation. The actual
implementation of the dissemination procedure by the Cospas-Sarsat network will
determine the schedule of the operational RLS.
GALILEO Mission
Segment (GMS)
GMS-E
GMS Emulator
RLSP
Return Link Service
Provider prototype
CSNE
Cospas-Sarsat
Network Emulator
FMCC Toulouse Space Centre
Prototype
MEOLUT
Cospas-Sarsat
SAR Galileo Beacon
406 MHz Uplink with
Distress Message and
Return Link Message
Request
Navigation Signal
L1 with Return
Link Messages
L-band
Downlink
7-7
7.2.3
406 MHz Beacons with SAR/Galileo RLS Capability
7.2.3.1 Beacon Definition
406 MHz beacons with the SAR/Galileo RLS capability will meet document C/S T.001
specifications regarding the forward link message transmission. In addition, the design
will include a Galileo compatible navigation receiver and a processor able to recover
Return Link Messages included in the Galileo navigation signal. The beacon will
identify the specific RLM with its own recipient ID address and react in accordance with
planned actions (see section 7.1.1). Prototypes are available as test equipment for use
in the SAR Galileo RLS IOV. The development of operational beacons with an RLS
capability is in progress.
For the Galileo IOV, RLS capable beacons will be coded as described in section 7.2.3.2,
i.e. with a Cospas-Sarsat test protocol. MCC(s) participating in the RLS IOV will have
the beacon identifications on file and will be able to recognize and transmit the RLM
request to the RLSP.
Operational beacons compatible with the Cospas-Sarsat System and meeting
international requirements (i.e. ETSI, RTCM, RTCA, EUROCAE) must be available
before the Return Link Service is declared at Initial Operational Capability (see section
10.4).
Amendments to Cospas-Sarsat beacon documentation (documents C/S T.001,
C/S T.007 and C/S G.005) are required for allowing the development and type approval
of operational 406 MHz beacons with the SAR/Galileo RLS capability.
Considering the fact that the Return Link Service will be available well before the Full
Operational Capability of the MEOSAR system, the introduction of RLS beacons is
foreseen to take place in two steps:
– 1st Step: Introduction of the RLS capability in legacy 406 MHz beacons through the
definition of a specific protocol for coding the RLM request.
– 2nd Step: Introduction of the RLS capability in next generation beacons. This action
will be coordinated with other possible modifications of existing requirements aimed
at optimizing the performance of beacons used with the MEOSAR system. Possible
specification changes include the 406 MHz transmit antenna pattern and the use of
new modulation techniques which, together with other possible improvements,
would define a new type of uplink message (see section 7.3).
7.2.3.2 Test Protocol for Identification of RLM Requests in FLAMs
For RLS testing, the “Test National Location” protocol (protocol code “1111” in bits 37
to 40) will be used.
7-8
Figure 7.4: RLS Location Protocol Format
1
24→
27
36→
37
40→|41
85→
|
86
106→
115
132→
133
144→
------
61 BITS -----→
PDF-1
BCH-1
------
26 BITS
-----→
PDF-2
BCH-2
F
O
R
M
A
T
&
P
R
O
T
O
C
O
L
F
L
A
G
26 BITS
IDENTIFICATION
19 BITS
LATITUDE
LONGITUDE
S
U
P
L
E
M
E
N
T
A
R
Y
D
A
T
A
LATITUDE
LONGITUDE
C
O
P
R
BIT & FRAME
SYNCHRONIZ
.
PATTERNS
U
N
T
R
Y
C
O
D
E
O
T
O
C
O
L
C
O
D
E
B
E
A
C
O
N
T
Y
P
E
R
L
S
T
A
C
RLS
ID
S
E
R
I
A
L
N
U
M
B
E
R
N
S
D
E
G
R
E
E
S
0 - 90
(1/2 deg)
E
W
D
E
G
R
E
E
S
0 - 180
(1/2 deg)
21-BIT BCH
ERROR
CORRECTING
CODE
-
+
M
I
N
U
T
E
S
0 - 15
(1m)
S
E
C
O
N
D
S
0 - 56
(4 s.)
-
+
M
I
N
U
T
E
S
0 - 15
(1m)
S
E
C
O
N
D
S
0 - 56
(4 s.)
12-BIT BCH ERROR
CORRECTING
CODE
107 = Encoded Position Data Source: 1 = Internal, 0 = external
F=1 1101 “00” =ELT 108 = 121.5 MHz Homing: 1= Yes, 0 = No
P=0 “01”=EPIRB 109 and 110 = Return Link Message (RLM) Request
“10”=PLB 111 and 112 = Beacon Feedback (on receipt of RLM)
“11”=RLS Location Test protocol 113 and 114 = Return Link Service (RLS) Provider
7-9
7.2.3.3 Operational Protocol for Identification of RLM Requests in FLAMs
Table A2-B in document C/S T.001 shows that two combinations of the protocol code
(bits 37 to 40) are available as spare, i.e. “1001” and “1101. The spare protocol code
“1101” will be used to define a new Location protocol for identifying an RLS capable
beacon in the FLAM, which will be referred to as the RLS Location protocol.
The format of the RLS Location protocol is identical to the National Location protocol
format except for the first two bits of the 18 bit national ID code, which are used for
defining the beacon type as illustrated in Figure 7.4. In addition, the six bits 127 to 132
are assigned for RLM use. The bit pattern “100000” will be used for informing the
RLSP of an RLM request.
7.2.4 Return Link Message Content Definition
The Return Link Messages to be received by RLS capable beacons are included in the
Galileo navigation signal-in-space (SIS). A description of the RLM contained in the
Galileo SIS is provided in Chapter 4.3.7 "SAR Field Structure" of the “Galileo Open
Service Signal In Space Interface Control Document - Draft 1 (OS SIS ICD
Draft 1)”available at the following web site address:
www.gsa.europa.eu/go/galileo/os-sis-icd/galileo-open-service-signal-in-space-interface-
control-document
7.2.4.1 Basic RLM Structure
The RLM SAR data is defined in the Galileo Signal-in-Space Interface Control
Document (SIS-ICD) as follows:
Each RLM shall contain the following data included in the Galileo SIS as defined in
chapter 4.3.7 of the SIS ICD document:
- Beacon ID (60 bits): the Cospas-Sarsat 15 Hex characters identification
- Message Code (4 bits)
- Parameters (16 bits for the short RLM, 96 bits for the long RLM)
The ‘Beacon ID’ field is used by the beacon to decide whether it is the intended recipient
of the received RLM or this RLM is addressed to some other beacon.
The ‘Parameters’ field contains information that SAR services wish to send to the
Galileo RLS-capable beacon.
Short-RLMs are used to provide the activated beacon with a short acknowledgement or
various kinds of commands (e.g. to reduce its transmission rate).
Long-RLMs are intended for more complex commands in which several parameters may
be required (e.g. to provide operational information or the coordinates of a location).
7-10
Figure 7.5: Return Link Message Structure
RLMs are sent to Galileo RLS-capable beacons (or other dedicated receivers) using the
Galileo Open Service. Short RLMs could be primarily associated with automatically
generated acknowledgements, while long RLMs might be used for RCC-generated
messages relating to operational aspects of the rescue.
7.2.4.2 Definition of RLM Data Fields
[ section to be further refined ]
a)
60-bit Beacon ID
This field content is identical to the 60 bit (15 Hexadecimal characters) of the standard
beacon identification defined in the C/S T.001 document. It uniquely identifies the
beacon to which the RLM is addressed.
The Beacon ID field consists of:
- Protocol Flag (1 bit): 1= User protocols; 0 = other protocols.
- Country Code (10 bits)
- Beacon Identification (49 bits), as specified in C/S T.001, Annex A, with default bits
for National or Standard Location protocol beacons.
b)
4-bit Message Code
Two classes of RLMs have been identified:
i. the standard message type, where the first 60 bits are used per the C/S T.001
definition of the beacon identification; and
ii an alternative message type, where only the 4 message code bits are defined as well
as the last (parity) bit, while all the other bits are open for later determination (this
may even allow chaining messages into mega-messages, should this ever be needed).
A possible alternative message is foreseen for broadcasting to a specific geographical
area or region, not to any specific beacon.
Beacon ID (15 Hex ID)
Parameters
.
Short RLM (80 bits)
Code
.
Long RLM (160 bits)
Beacon ID (15 Hex ID)
Parameters
Code
7-11
c)
RLM Parameters
The detailed definition of the RLM parameters is still open. The last bit of this field, i.e.
bit 16 in the short-RLM and bit 96 in the long-RLM, is reserved for a final parity check.
The available capacity (15 unassigned bits on the short-RLM, 95 unassigned bits on the
long-RLM) can be used for a variety of applications.
Even though the navigation data is broadcast with a very robust link margin, the RLM is
assembled after a long segmented reception period, in four segments over 8 seconds for
short-RLMs or eight segments over 16 seconds for long-RLMs. Furthermore, the
environmental conditions of the reception are potentially very difficult and changing in
time. Therefore, a final post-assembly check of the RLM validity using the last parity bit
is required.
7.2.4.3 RLM Messages for the SAR/Galileo IOV
At this stage of development, for the IOV, only the standard type of the short or long RLM
is required for providing an automatic acknowledgement. The short/long message
information is included in the SIS format (see the SIS.ICD, Chapter 4.3.7, Table 53). The
four bits of the message code define the type of message:
- message code 0000: automatic acknowledgment without significant parameters (15 or
95 bits),
- message code 0001: automatic acknowledgment with significant parameters (15 or
95 bits).
7.2.5
Return Link Service Provider (RLSP)
The RLSP is the unique interface point between the Galileo Mission Segment (GMS) and
the Cospas-Sarsat System. Although mostly devoted to the RLS, the RLSP is in charge of
providing Cospas-Sarsat MEOLUT Operators with SAR/Galileo system information such
as operational functionalities and monitoring status.
This configuration will be maintained for the IOV of the SAR/Galileo RLS. The FMCC
will take part of the validation of the Return Link Service in the IOV phase using the
European prototype MEOLUT and prototype RLSP.
During the development of the RLS capability, other MCCs will be invited to participate
in the RLS validation by implementing the defined RLS processed in their MCC and using
their LEOLUTs, GEOLUTs and experimental MEOLUTs.
[Text will be further developed specifying the user operational interfaces to the RLSP.]
7-12
7.2.6
RLS Data Exchange
7.2.6.1 Description of Interfaces between the Cospas-Sarsat Ground Segment, the
SAR/Galileo RLSP and RCCs for the Return Link Acknowledgment Service
Cospas-Sarsat MCCs will forward the RLM requests received by the LUTs to the
SAR/Galileo RLSP. The RLSP will process this information and eventually instruct the
Galileo Mission Segment to send a Return Link Message in accordance with the
SAR/Galileo RLS internal procedures.
The action performed by a beacon when it receives a Return Link Message is the following.
When the beacon receives the Return Link Message, it modifies the content of the FLAM
(Acknowledgement of Return Link Message Reception). This acknowledgment of
reception is received by the LUTs and forwarded to the RLSP through the Cospas-Sarsat
System. The beacon will receive the Return Link Message from the Galileo system (via the
RLSP) until the RLSP is notified of the reception of the RLM by the beacon or until a time-
out is reached should this confirmation of reception never be received by the RLSP.
Figure 7.6.1 shows the interfaces between the various system components involved in a
Type 1 acknowledgment of the RLS, also called the System acknowledgment with RLM
reception notification by the beacon.
Figure 7.6.2 shows the interfaces between the various system components involved in a
Type 2 acknowledgment of the Return Link Service, also called the RCC Acknowledgment
with RLM reception notification from the beacon.
7-13
F.7.6.1: RLS data exchange overview for Type 1 Acknowledgment
F.7.6.2: RLS data exchange overview for Type 2 Acknowledgment
Figure 7.6: RLS Data Exchange Overview
7-14
Notes:
● In Figures 7.6.1 to 7.6.2, the term “MCC” designates the associated MCC for the LUT, while
the term “MCC\*” designates the MCC for the service area where the distress is located. This
MCC* receives the distress alert either from its associated LUTs or from the Cospas-Sarsat
MCC network as defined in document C/S A.001 (DDP).
● In Figures 7.6.1 to 7.6.2, the FMCC receives the RLS information from the MCC* in charge
of the SAR interface (the MCC for the service area where the distress is located). Routing
of this information may involve another nodal MCC.
The introduction of the RLS acknowledgment service within the Cospas-Sarsat System will
initially be based on the System Acknowledgment (Type 1, under RLSP responsibility).
The interfaces involved in the RCC acknowledgment (Type 2) are similar to those involved
in a Type 1 acknowledgement, but are completed with specific MCC to RCC and RCC to
RLSP interfaces.
Table 7.1 summarises the various interfaces involved in the Return Link Acknowledgment
Service.
7.2.6.2 RLS Impact on the Cospas-Sarsat Ground Segment
- MCC Return Link Alert Data processing
All MCCs shall be able to perform the RLS actions defined in 7.2.6.1 when an RLS
alert, identified by its coding protocol, is located in its service area.
- SIT 135
This new SIT message will be sent by the MCC associated with the SAR area to the
FMCC for transmission to the RLSP.
- DDP updates
To be developed
- SID updates
To be developed
7-15
Table 7.1 - Cospas-Sarsat and Galileo Interfaces involved in the Return Link Acknowledgment Service
Interface
Interface content
Information processing
Comment
Beacon ➔ LUT
(LEO, GEO, MEO)
Forward Link Alert Message (FLAM):
Location protocol adapted for RLS
application. The coding protocol used by
C/S RLS beacons is defined in section 7.2.6.
The LEO, GEO and MEO LUTs will receive and process the FLAMs for location
determination (when possible) and FLAM content recovery and analysis.
LUT ➔ MCC
The LUT forwards the alert information to its
associated MCC.
C/S does not specify the LUT/MCC interface. As for the other location protocols,
the LUT provides the MCC with all information necessary for preparing standard
SIT 122 to 127 and 132, 133 (no change). The specific RLS information is
provided by the 30 Hex beacon message in the SITs’ MF\#23.
No change required for C/S in
case of Option 1 (no
acknowledgment of RLM
reception by the beacon, thus
no modifications to FLAM)
MCCs ➔ Associated
MCC\*
The alert information is processed by the
MCC network in accordance with existing
DDP procedures.
Except for the associated MCC in charge of the SPOC/RCC interface, the
processing of alert information provided by the SIT messages will be unchanged.
No change required at
Cospas-Sarsat level
Associated MCC ➔
FMCC
After the confirmation of the alert location,
the Associated MCC prepares and sends a
new SIT 135 to inform the RLSP (via the
[FMCC]) of the requests and cancellations of
Return Link messages.
The Associated MCC first process the incoming SIT messages as currently
defined in the DDP and SID (SIT 185).
In addition, after the confirmation of the alert, it processes the RLS bits in the 30
Hex. of the message, prepares and sends a SIT 135 to the FMCC.
The DDP data routing matrix, Figure III/A.8, may be used for routing the SIT 135
message to the unique interface point between the C/S network and SAR/Galileo
[FMCC].
Change in MCC processing
required
FMCC ➔ RLSP
The FMCC informs the RLSP of the RLM
request (SIT 135 can be re-used).
Change required at FMCC /
RLSP interface only
RLSP ➔ GMS
Internal SAR/Galileo interface.
Associated MCC ➔
SPOC/RCC
An updated SIT-185 is used to transmit alerts
to RCC. The updated SIT 185 includes RLM
request information.
After the confirmation of the alert location, the Associated MCC in charge of the
SPOC/RCC interface (alert location in its service area) sends a SIT 185 to the
relevant SPOC/RCC with the mention “THIS BEACON HAS A RETURN LINK
CAPABILITY” in MF \#62.
SPOC/RCC ➔ RLSP
TBD
Mechanism still TBD for RCC activation of RLM Type 2 Ack.
No change for Cospas-Sarsat
Only applicable to Type 2
Acknowledgement
GMS ➔ Beacons
The RL Messages are included in the Galileo
navigation signal as defined in section 7.2.7.
Note:* The associated MCC is the MCC in charge of the SPOC/RCC interface: i.e. the alert position is in its service area.
7 - 16
7.3
Improved 406 MHz Beacon Signals
The Cospas-Sarsat 406 MHz beacon specification was originally developed to optimise the
detection and Doppler location performance of the LEOSAR system. Because the MEOSAR
system will employ different location determination techniques, it might be possible to improve
MEOSAR performance by changing the 406 MHz beacon transmission characteristics.
Preliminary studies conducted by France and the USA indicate that changes to the 406 MHz
channel coding (e.g. coding for error detection and correction) for improving the processing
gain are possible. Improved processing gain would reduce the overall bit error rate, thereby
increasing the probability of decoding the beacon message. Another option being considered
is possible changes to the content of beacon messages that would enhance MEOSAR system
effectiveness, and/or simplify beacon coding requirements.
With respect to possible new 406 MHz beacon modulation waveforms, the Sarsat SARP-3
instruments developed by France will support an additional modulation format called mixed
QPSK, also known as MQPSK. The efficient channel coding associated with MQPSK will
improve the beacon – satellite – LUT link margin by several dB. Such an improvement might
be particularly beneficial for a MEOSAR system, where the greater satellite to ground distances
result in a poorer link margin than that provided by LEOSAR systems.
Any new beacon specifications, or changes to existing specifications should be:
a.
approved by the Cospas-Sarsat Council and coordinated with international organisations
as appropriate;
b.
as spectrum efficient as current 406 MHz beacons;
c.
supported by extensive analysis and testing; and
d.
accompanied with the necessary type approval requirements.
Action Item 7.4:
Cospas-Sarsat and MEOSAR providers should conduct analyses to identify
improvements to the 406 MHz beacon specification for the MEOSAR system. The following points
should be specifically addressed:
a.
changes in the channel coding (e.g. convolutional coding);
b.
the impact that new beacon specifications would have on System capacity;
c.
new modulation techniques to improve TDOA/FDOA performance;
d.
improvements to the message format;
e.
additional encoded data requested by SAR authorities;
f.
general optimisation of beacon parameters;
g.
technologies that could reduce the cost of the beacon; and
h.
the suitability of the MQPSK modulation for the MEOSAR TDOA time-tagging
requirement.
- END OF SECTION 7 -
8-1
8.
MEOSAR GROUND SEGMENT
The four MEOSAR programmes each will provide a satellite constellation that will support
global coverage, and include the development of prototype MEOLUTs for use in the proof of
concept (POC) and demonstration and evaluation (D&E) phases. However, none of the
programmes will provide all the MEOLUTs necessary for global coverage. Instead, the
provision of MEOLUTs will be a national responsibility, and the programmatic requirements
and responsibilities for providing and operating MEOLUTs will have to be formulated during
the development and proof of concept phases of the MEOSAR programmes.
8.1
MEOSAR Ground Segment Concept and Architecture
The MEOSAR ground segment will be comprised of Cospas-Sarsat MEOLUTs, the existing
Cospas-Sarsat MCC network, and possibly ground control stations for implementing return
link functions. The principal function of the MEOLUT is to receive and process satellite
downlinks, calculate 406 MHz beacon locations, and forward this information to the MCC
associated with the MEOLUT. The MCC network will perform the same basic functions for
MEOSAR alerts as they currently provide for LEOSAR and GEOSAR alerts (e.g. distribute
alerts to other MCCs or SAR points of contact as per the Cospas-Sarsat Data Distribution Plan,
validate alert data, filter-out redundant data, etc.).
Unlike LEOLUTs which track a single satellite at a time and derive Doppler location
information from a single satellite pass, a MEOSAR system requires multiple simultaneous
time and frequency measurements to calculate beacon locations to the required accuracy.
MEOSAR location accuracy is also affected by the beacon / satellite geometry. As a
consequence, the probability of providing independent location information and the accuracy
of the location data would decrease when the distance of a beacon to the MEOLUT increases.
Specifically, ambiguity resolution could become problematic at the edge of a MEOLUT
coverage area. Two approaches can be used to mitigate these potential problems:
-
design MEOLUTs that can track as many satellites as possible, i.e. satellites from
all available constellations; and/or
-
design MEOLUTs that operate as a network, i.e. MEOLUTs that can exchange
beacon burst time and frequency measurements with adjacent MEOLUTs.
The terminology applicable to the various MEOSAR ground segment concepts and possible
architectures is provided at Annex A to this document.
8-2
8.1.1
Stand-Alone MEOLUTs
MEOLUTs with the capability of simultaneously receiving and processing the downlinks
of multiple MEOSAR satellites will provide a stand-alone beacon location capability that
extends to a radius of around 6,000 to 7,000 kilometres centred on the LUT. The number
of stand-alone MEOLUTs that would be required to achieve complete coverage depends
on a number of factors such as:
•
the number of operational satellites available in orbit;
•
MEOSAR system performance requirements;
•
operational requirements in terms of redundancy; and
•
the actual geographical location of the MEOLUTs.
Studies show that a minimum of six MEOLUTs suitably situated around the world would
provide for global MEOSAR coverage.
8.1.2
Networked MEOLUTs
The basic advantages of networking MEOLUTs include:
•
increased coverage due to geographically dispersed MEOLUTs sharing data in
order to increase the input to location processing algorithms;
•
increased fault tolerance and backup capability; and
•
reducing or eliminating regions with reduced location accuracy, as the computed
location accuracy decreases when distance to the MEOLUT increases.
MEOLUT networking is expected to be essential during the pre-operational phase of the
MEOSAR system, when the limited number of satellites will directly impact the
capability of MEOLUTs to locate beacons. With complete MEOSAR constellations in
a fully operational MEOSAR system, MEOLUT networking will continue to be
beneficial for enhanced performance and redundancy. Networking MEOLUTs will
augment the coverage of stand-alone MEOLUTs, providing for the location of beacons
at the fringe of their coverage area.
A number of issues need to be addressed before implementing the networking of
MEOLUTs on an operational basis, including:
•
programmatic issues concerning IT security; and
•
operational and technical issues related to the provision of reliable communications
and increased requirements for measurement calibrations.
8.1.3
Ground Segment Architecture
The requirement to develop a ground segment architecture is to have enough
infrastructure to ensure global coverage with high level of availability [99.9%]. While
dependent MEOLUTs provide capability to the system, they do not provide the
8-3
independent location and coverage that a stand-alone MEOLUT provides. In constructing
a MEOLUT architecture it is preferred that stand-alone MEOLUTs be planned for as the
fundamental unit in the optimum architecture. The following are agreed upon principles
for developing the MEOSAR system ground segment.
Global coverage for the Cospas-Sarsat MEOSAR system should be achieved by a
distribution of stand-alone MEOLUTs, with no reliance on MEOLUT networking to
satisfy the performance requirements of the full operational capability.
MEOLUT networking should be implemented to enhance system performance and
support redundancy of the Cospas-Sarsat Ground System.
The following principles and standards should be used in the development of MEOLUT
networks:
a)
the approach used in the pre-operational phases of the system should remain
flexible to allow for the evolution towards an operational status and should not limit
system capabilities or preclude future enhancements;
b)
during the pre-operational phase, the networking architecture should use the hybrid
concept illustrated at Annex L, to provide the primary distribution of MEOLUT
burst measurement data;
c)
the local implementation of MEOSAR data servers should remain the prerogative
of the MEOLUT operator, taking into account local infrastructures and practices,
particularly with regard to IT security constraints;
d)
burst data should be stored on the data servers in the format specified at Annex L
and the exchange of burst data should be made using the message definitions and
data contents provided at Annex M; and
e)
MEOLUTs should have the capability to exchange data with any other MEOLUT
as per Annex L, but should not be required to connect to any other MEOLUT.
Annex L also contains optional topologies and data transfer methodologies (e.g., data
forwarding) which may facilitate global availability of MEOLUT burst measurement
data.
8.1.4
International MEOLUT Networks
Sharing MEOLUT measurements internationally raises several policy, management,
technical, and operational issues requiring further study.
At present, each Cospas-Sarsat administration is responsible for the operation and
performance of its own ground segment equipment. If raw and / or semi-processed
MEOLUT data were shared internationally, then the performance of MEOLUTs would
be affected by the performance of equipment operated by other administrations. In view
of this, further analysis is required in respect of:
8-4
•
the suitability and implications of networking MEOLUTs internationally;
•
procedures for sharing data internationally; and
•
specifications and commissioning requirements for sharing MEOLUT data.
The Demonstration and Evaluation phase should provide the data necessary to enable the
analysis for the implementation of international MEOLUT networking as appropriate. It
is anticipated that networking will be implemented prior to Demonstration and
Evaluation.
8.2
MEOLUT Requirements
The main role of a MEOLUT is to track MEOSAR satellite(s), measure the time and frequency
of beacon bursts relayed by MEOSAR satellites, possibly interface with other MEOLUTs to
obtain additional beacon burst time and frequency measurements, calculate the location of 406
MHz beacons, and provide distress alert messages from active 406 MHz beacons to the
MEOLUT’s associated MCC.
8.2.1 Satellite Tracking
It is desirable that MEOLUTs be capable of simultaneously tracking and processing the
downlinks from all satellites in a given MEOSAR constellation that are in the
MEOLUT’s field of view. This would minimise its reliance on other MEOLUTs for
providing beacon burst time and frequency measurements, and provide options in
selecting satellites with the best geometry to the beacon for location processing.
Depending on MEOSAR downlink design options, it is likely that MEOLUT cost and
complexity will increase as a function of the number of satellites they are capable of
tracking and processing simultaneously.
Analysis should be carried-out to determine an appropriate MEOLUT requirement in
respect of the number of satellites that MEOLUTs should be capable of simultaneously
tracking, taking into account MEOLUT costs, complexity, and performance.
8.2.2 Tracking Satellites from Different MEOSAR Constellations
Separate studies conducted by the USA and ESA (EWG-2/2003/4/4 and
EWG-2/2003/4/13-Rev.1 respectively) clearly show that there are benefits to providing
MEOLUTs that are capable of receiving and processing the downlinks of MEOSAR
satellites from different constellations. These benefits include:
a.
improved MEOSAR system redundancy;
b.
the possibility of reducing the time required to deploy a MEOSAR space segment
that provides permanent global coverage;
c.
an improvement to the location accuracy on the first beacon burst from over 6 km
95% of the time in the case of a single constellation, to about 4 km 95% of the time
8-5
when MEOLUTs have access to two complete MEOSAR satellite constellations;
and
d.
an increase in MEOLUT local coverage area from a 6,000 km radius for
SAR/Galileo system alone to approximately 7,000 km for combined DASS –
SAR/Galileo constellations.
The feasibility of implementing a MEOSAR system comprised of fully interoperable
satellite constellations is dependent upon the decisions taken by MEOSAR providers for
the downlinks of their respective systems. The degree of interoperability achieved
between the four MEOSAR constellations will also impact MEOLUT cost and
complexity.
8.2.3
MEOLUT RF Chain
As discussed at section 5.3.3, MEOSAR independent location accuracy performance is
dependent upon the accuracy of the measurements of beacon burst time and frequency
by the MEOLUT, which in turn are affected by the beacon carrier to noise density ratio
available at the MEOLUT processor. Further analysis is needed to identify MEOLUT
antenna and receiver requirements necessary to achieve the desired MEOSAR system
performance.
8.2.4
Suppressing Redundant Information
MEOLUTs will be capable of calculating beacon location information from a single
beacon burst that has been relayed by multiple MEOSAR satellites. Therefore, in view
of the coverage available from a MEOSAR system, it is possible that MEOLUTs might
produce new beacon location information every time a beacon transmits a burst, resulting
in over 70 solutions per beacon per hour. Because of the large number of solutions that
will be available for each active beacon, procedures will be required for determining
which solutions should be forwarded to the MCC, and which solutions should be
suppressed at the MEOLUT.
It may be feasible to send every alert message to the MCC, in which case it would be an
MCC function to determine whether specific alert messages should be distributed further.
Conversely, if it is possible to establish criteria for estimating the accuracy of specific
solutions at the MEOLUT, it might be preferable to incorporate features in the MEOLUT
to suppress redundant solutions.
8.2.5
Beacon Message Processing
The LEOLUT and GEOLUT specifications (C/S T.002 and C/S T.009) include
requirements for validating and confirming the content of beacon messages. The
validation and confirmation procedures have been developed to provide confidence that
beacon message information provided by LUTs is reliable. Although the LEOLUT and
GEOLUT procedures differ, they are both based on receiving beacon information from
a single satellite. Since MEOLUT processing is based on obtaining beacon information
8-6
from multiple satellites, a different validation and confirmation process might be
required.
In a MEOLUT network, only burst data corresponding to valid beacon messages should
be placed on the MEOSAR data servers for exchange among MEOLUTs.
8.2.6
Burst Time and Frequency Measurement Data
The accuracy of location data computed by a MEOLUT is dependent upon the accuracy
of the time and frequency measurements performed for each MEOSAR beacon event
(see the definition of a MEOSAR Beacon Event at Annex A). A uniform convention
should be used by all MEOLUTs for burst time and frequency measurements. In
particular, burst frequency data should be provided with reference to the same burst time
defined in accordance with the agreed burst timing convention.
Burst data formats and contents to be made available to networked MEOLUTs are
defined at Annex L and M to this document. Networked MEOLUTs should be capable
of exchanging these data on request via MEO data servers as described at Annex L, using
the SIT message formats described at Annex M to this document.
8.2.7
Interferer Processing
As described at section 5, studies conducted by the USA indicate that a MEOSAR system
should be able to locate 406 MHz interferers. However, additional study is required to
identify specific MEOLUT interferer location determination techniques most suitable to
the transmission characteristics of the interference signal.
8.2.8
Data Channels
MEOLUTs should be capable of receiving and processing the entire bandwidth of the
MEOSAR satellite downlinks.
Action Item 8.1:
Cospas-Sarsat and MEOSAR providers should conduct analysis on the
feasibility of developing MEOLUTs and identifying the associated LUT technical
characteristics necessary for simultaneously receiving and processing the downlinks from:
a.
multiple MEOSAR satellites from the same MEOSAR constellation; and
b.
multiple MEOSAR satellites from different MEOSAR constellations.
Action Item 8.2:
Cospas-Sarsat and MEOSAR providers should conduct analysis and
propose options for a MEOLUT ground segment architecture. The analysis should specifically
address advantages and disadvantages of networking MEOLUTs, propose options for sharing
MEOLUT beacon burst data measurements with other MEOLUTs, and identify specification
and commissioning requirements for the MEOLUT data sharing function.
Action Item 8.3:
Cospas-Sarsat and MEOSAR providers should conduct analysis and
propose MEOLUT functional, technical and commissioning requirements, that ensure that
8-7
MEOLUTs will be capable of providing a service that satisfies the performance requirements
identified at section 5.
- END OF SECTION 8 -
9-1
9.
MEOSAR SYSTEM CALIBRATION
To perform reliable TDOA / FDOA measurements and location processing, MEOLUTs require
reliable and timely calibration data. The calibration information needed, and the update
frequency, is affected by many factors including:
a.
variations in MEOSAR payload technical characteristics from satellite to satellite;
b.
the rate of change of payload characteristics over long, medium and short time periods;
c.
the ground segment architecture (e.g. standalone MEOLUTs or MEOLUTs which share
time and frequency measurements); and
d.
bias errors introduced at the MEOLUT.
There are a number of options that might be suitable for obtaining calibration information,
including:
• specialised processing of periodic transmissions from reference beacons;
• data from onboard satellite telemetry; and
• tests performed locally at individual MEOLUTs which might not necessarily involve
the processing of signals relayed by MEOSAR satellites.
9.1
Satellite Payload Calibration
TBD
9.2
Signal Path Delay
TBD
9.3
MEOLUT Time Measurement Calibration
TBD
9.4
MEOLUT Frequency Measurement Calibration
TBD
9-2
Action Item 9.1:
MEOSAR providers should conduct studies and trials to identify:
a.
what calibration information will be required to support Cospas-Sarsat performance
requirements;
b.
the required update frequency of calibration information; and
c.
the most appropriate methods for obtaining and distributing calibration information.
-
END OF SECTION 9 -
10-1
10.
PROCEDURES FOR MEOSAR INTRODUCTION INTO COSPAS-SARSAT
Prior to distributing distress alert data from LEOSAR and GEOSAR systems to SAR services,
extensive demonstration and evaluation (D&E) programmes were conducted by Cospas-Sarsat.
Specifically the LEOSAR D&E Report was approved by the Cospas-Sarsat Coordinating Group
(CSCG) in 1984 before declaring the LEOSAR system operational. Similarly the Cospas-Sarsat
Council at its 21st Session in October 1998 adopted the GEOSAR D&E Report before
incorporating GEOSAR elements into the Cospas-Sarsat System. In accordance with the same
principles that were followed for the LEOSAR and GEOSAR systems, a MEOSAR system will
have to undergo an extensive test and evaluation period to validate its performance prior to its data
being used operationally.
The MEOSAR system should be implemented in several phases to clearly delineate
development and implementation activities. The various activities can be summarised in the five
phases described below. The time estimates for the various stages are not definitive and can
overlap to show that some activities will occur concurrently. For example, it may be possible
to start using operational data prior to having all satellites in orbit operating in their final
configuration. In most cases, activities in each stage will have to be successfully completed
before substantial work can be initiated in the following stage.
10.1
Definition and Development Phase
During this phase MEOSAR providers and Cospas-Sarsat focus on identifying MEOSAR system
functional and performance requirements, as well as matters relating to MEOSAR / Cospas-Sarsat
compatibility. MEOSAR providers also refine the high-level functional and performance
requirements into more detailed technical specifications suitable for building MEOSAR space
segment and prototype ground segment equipment.
Work should also start in developing Cospas-Sarsat specification and commissioning
requirements for all MEOSAR components, although these specifications and commissioning
standards will continue to be enhanced during subsequent programme phases and will not be
finalised until the D&E results have been analysed.
The coordination of MEOSAR performance requirements and system characteristics required
to ensure the compatibility and interoperability is conducted under the ICSPA during the
definition and development phase.
MEOSAR satellites in orbit with SAR capability are not required during this phase. However,
after completion of the requirements analysis and design, MEOSAR providers should develop
prototype ground stations to be used during the proof-of-concept, and the demonstration and
evaluation phases. Cospas-Sarsat Participants should be kept informed of the development
efforts undertaken by the MEOSAR providers, and system specifications should be shared with
interested Participants, as appropriate.
10-2
Ground Segment operators, other than MEOSAR providers, could be invited to participate in
the development of the MEOSAR ground segment. However, Ground Segment operators and
User States are not required to participate during this phase. More importantly, the
development of the MEOSAR system should not detract Cospas-Sarsat Participants from
upgrading their existing LEOSAR and GEOSAR ground segment equipment as these systems
will continue to be the primary distress alerting source for the foreseeable future.
10.2
Proof of Concept / In-orbit Validation Phase
The proof-of-concept (POC) / in-orbit validation phase, hereafter referred to only as the proof-of-
concept phase, of MEOSAR programmes will assess the basic capabilities of the MEOSAR
system and establish preliminary performance levels that will be used to focus the scope and
content of the MEOSAR D&E phase. This is the first test stage.
The proof-of-concept phase will focus on confirming the capabilities of the MEOSAR space
and ground segments. Proof-of-concept testing will include as a minimum:
a.
confirmation of the ability to reliably receive and process emergency beacon signals
(i.e. confirm the performance of the link from the beacon to the satellite and the ground
station);
b.
an evaluation of location processing algorithms;
c.
an assessment of the performance of detection and location processing with degraded
system components (e.g. less than four satellites in view, malfunctioning beacons, etc.);
and
d.
the confirmation of the ground segment architecture (e.g. tracking satellites with receive
only phased-array antennas).
During the POC phase, MEOSAR providers continue co-coordinating with Cospas-Sarsat on
compatibility and interoperability issues under the auspices of the ICSPA. While DASS and
SAR/Glonass can be viewed as “enhancements” to the existing LEOSAR and GEOSAR
systems, a specific arrangement should be established with the SAR/Galileo management
organisation to formalise the relationship with the Cospas-Sarsat Programme.
The number of satellites required to conduct the proof-of-concept will depend on the orbital
planes of the available MEOSAR satellites. At least three to four satellites will need to be in
view of the ground station and the beacon to confirm the detection and location processing
performance.
The primary ground stations to be used during the proof-of-concept phase will be the prototype
stations developed during the previous phase. A global ground segment is not envisioned
during this phase. However, if other Cospas-Sarsat Participants have established MEOSAR
ground segment equipment, they should be invited to participate in the proof-of-concept trials.
There will be no distribution of operational distress alert data to SAR services during the proof-
of-concept phase.
10-3
Successful completion of the proof-of-concept phase will initiate the transition to the
demonstration and evaluation phase.
10.3
Demonstration and Evaluation Phase (D&E)
The demonstration and evaluation phase will focus on characterising the technical and operational
performance of the MEOSAR system, evaluating the operational effectiveness and the benefits to
SAR services, and providing a basis for a Cospas-Sarsat Council decision on the use of the
MEOSAR system operationally. This assessment of MEOSAR system performance is required
for national and international organizations (e.g., ICAO and IMO which mandate the use of
beacons and accept distress alerting systems, ITU which regulates the use of the frequency bands,
and Cospas-Sarsat Participants that provide and use the new alerting system) to accept the
MEOSAR system as an alerting source.
Typical demonstration and evaluation periods in Cospas-Sarsat span a number of years. A
thorough evaluation is particularly important as the MEOSAR system could significantly alter the
Cospas-Sarsat System architecture in the long term. Therefore, although the demonstration and
evaluation period for the GEOSAR system was limited to two years, the importance of the
MEOSAR D&E, combined with the development of new specifications and System
documentation, might require extending the D&E period to more than two years.
Sufficient MEOSAR capability in terms of space and ground segment will be required to
adequately characterise the system and confirm its benefits. During this phase all minimum
MEOSAR performance parameters required for compatibility with Cospas-Sarsat, with the
possible exception of global coverage, will be evaluated. Operational data should be provided to
the Cospas-Sarsat network for analysis, however, data should not be transmitted to SAR services
until the Council decides that the MEOSAR system has reached its early operational capability
(EOC). The demonstration and evaluation plan should provide guidelines for conducting the
demonstration and evaluation in a standard manner, collecting a set of results on an agreed basis,
and establishing a process for translating the results into a set of recommendations.
MEOSAR technical performance parameters to be evaluated include, but are not limited to:
•
detection probability including processing threshold and system margin;
•
message transfer time between activation of the beacon and availability of the first
valid message;
•
capacity of the system;
•
impact of interference on detection probability;
•
location accuracy and location error prediction;
•
reliability/sensitivity (i.e. BER);
•
availability of system;
•
coverage provided by ground stations that are not networked; and
•
system anomalies.
10-4
In addition, if MEOLUTs are designed to operate in a network, the performance enhancement
provided by the exchange of MEOLUT data, and possible drawbacks, should be assessed.
Furthermore, if as planned, MEOLUTs are capable of processing satellites from several
constellations, a specific evaluation of the performance achieved with the combined processing
capability should also be performed.
Operational performance parameters to be evaluated include, but are not limited to:
•
location accuracy of operational beacons;
•
potential time advantage of MEOSAR system over the existing System;
•
degree to which the MEOSAR system complements the existing System;
•
volume of distress alert traffic in the Cospas-Sarsat Ground Segment and impact
on communication networks; and
•
direct and indirect benefits of the MEOSAR system.
Because the D&E will be undertaken with a mixture of satellites with S-band and L-band
downlinks with different performance, it will require three phases to more confidently characterize
the expected operational MEOSAR system.
In Phase I, participants will perform only technical tests, carefully limiting the earliest tests to a
selected set appropriate for the limited space segment available. During Phase II of the D&E,
participants will attempt to demonstrate that the MEOLUT system can perform as well as, or better
than, the existing LEOSAR/GEOSAR system. Phase II will include both technical and operational
tests. It is possible that a set of these tests could form the basic testing sequence for future
MEOLUT commissioning.
In Phase III, when satellites with L-band downlinks will be widely available, a second series of
tests replicating the tests of Phases I and II will be accomplished.
A minimum of six MEOSAR satellites is required to start the demonstration and evaluation.
While it is recognized that initial technical characterisations can be completed without a full
constellation of 24 satellites, it is expected that at least 14 L-band satellites are needed to complete
the D&E.
All Cospas-Sarsat Participants will be invited to participate in the D&E. The detailed
description of the technical and operational testing to be performed during the D&E and the
procedure applicable for the distribution of alert data and the collection of test data will be
provided in a MEOSAR D&E Plan to be approved by the Cospas-Sarsat Council. Successful
completion of demonstration and evaluation activities should form the basis for a Council
decision on the operational use of the MEOSAR system.
International activities during this phase continue to fall under the ICSPA. However, the Cospas-
Sarsat Parties should begin an evaluation of the ICSPA to address long term issues associated with
the integration of the MEOSAR system.
10-5
Cospas-Sarsat Participants should be encouraged, as possible, to implement MEOLUTs to
participate in the demonstration and evaluation. Additional ground stations will be required for
the MEOSAR system to reach Full Operational Capability.
The primary ground stations to be used during the demonstration and evaluation phase will be the
prototype ground stations developed by the MEOSAR providers. Distress alert data from these
MEOLUTs should be transmitted to the associated Cospas-Sarsat MCC participating in the D&E
where it will be collected and made available for analysis. Data should also be exchanged among
Cospas-Sarsat D&E participants for their evaluation.
To terminate the D&E phase the Cospas-Sarsat Council will have to adopt a D&E Report that
provides official results of the evaluation, including the MEOSAR system performance data.
10.4
Early Operational Capability (EOC)
In preparation for Initial Operational Capability (IOC) and in order to ease the transition into
regular MEOSAR Operations, IOC will be preceded by a period of Early Operational Capability
(EOC) that can be initiated before the D&E Phase is complete. The EOC period will allow the
early use of operational MEOSAR alert data. The EOC period will also allow the initial MEOSAR
system to augment the performance of the LEOSAR/GEOSAR system and allow SAR services
to familiarise themselves with the MEOSAR system before the end of the D&E Phase.
At this stage, the MEOSAR system need not necessarily provide global coverage or may not fully
meet the expected performance requirements. However, operational MEOSAR alert data shall not
be distributed to search and rescue (SAR) services unless it has demonstrated a quantifiable benefit
and would not cause harm to the existing Cospas-Sarsat System.
The following milestones are required to be achieved for the declaration of EOC:
• the approval of the necessary operational documents (data distribution plan, MCC
standard interface description, MCC specifications and MCC commissioning
standards);
•
the approval of the necessary technical documents (MEOLUT specifications and
design guideline document, MEOLUT commissioning standard, MEOSAR space
segment description and MEOSAR space segment commissioning standard);
• the successful commissioning of all nodal MCCs, or their backup MCCs, and
successful commissioning of at least one MEOLUT associated with a
commissioned MCC;
• the capability to distribute operational MEOSAR data among commissioned
LEOSAR/GEOSAR/MEOSAR (LGM) capable MCCs,
• MEOSAR D&E Phase I and II test reports that validate initial MEOSAR
performance or a recommendation from the Joint Committee approved by the
Council that validate initial MEOSAR performance, such that the Cospas-Sarsat
Programme could allow the operational use of the MEOSAR data;
10-6
• notification to ICAO, IMO and national Administrations of the beginning of EOC;
and
• commissioned LGM MCCs shall have the capability to transmit, and all (both
LEOSAR/GEOSAR and LGM) MCCs shall have the capability to receive,
MEOSAR alert data in accordance with document C/S A.001 (DDP).
10.5
Initial Operational Capability (IOC)
Initial operational capability is a declaration by the Cospas-Sarsat Programme that the MEOSAR
system components provide reliable data and that MEOSAR data is being distributed
operationally between all data distribution regions. Compared to EOC, IOC is based on an
extended L-band space segment, an extended ground segment, and a completed D&E Phase.
The IOC declaration shall also be based on the experience gained through the operational use of
the system since the declaration of EOC. The MEOSAR system need not necessarily provide
global coverage during the IOC phase. This could be due to an incomplete satellite constellation
or an incomplete ground segment.
Most of the activities needed for MEOSAR alert data distribution should have been carried out
as part of the preparation to enter the EOC period, and therefore the remaining criteria to be
met to allow for the declaration of IOC include:
• D&E Phase III testing is complete and the Council has approved the final D&E
Phase II and Phase III test reports;
• operational and technical documents requiring modifications as a result of D&E
testing or EOC experience have been approved by the Council;
• operational document C/S A.003 (System Monitoring and Reporting), has been
approved by Council;
• slow-moving
beacon
location
performance
specifications
and
related
commissioning standard are completed and approved in document C/S T.019
(MEOLUT performance specifications) and in document C/S T.020 (MEOLUT
commissioning);
• all nodal MCCs are commissioned for LEO/GEO/MEO (LGM) capability;
• all nodal MCCs, or their back-up nodal MCC, provide at least one associated
MEOLUT commissioned to the requirements as per performance specifications and
commissioning standards for IOC/FOC;
• all MEOSAR satellites required to enter IOC are commissioned; and
• ICAO, IMO and national Administrations have been notified of the beginning of
IOC.
The processing of the RLS protocol by the Cospas-Sarsat Ground Segment is not an entrance
criterion for MEOSAR IOC.
10-7
The number of satellites required to operate in IOC will be determined during the
demonstration and evaluation phase. An initial assumption would be that at least 14 L-band
satellites would be needed to begin MEOSAR IOC.
All MEOLUTs commissioned at the MEOSAR EOC level will require a partial
recommissioning to verify conformance to the requirements as per performance specifications
and commissioning standard for IOC/FOC before they are considered to be operating at the
MEOSAR IOC level. Until this verification is complete, MEOLUTs may continue to operate
at the EOC level and provide valuable distress data to the system.
No new MEOLUT shall be commissioned at the MEOSAR EOC level after MEOSAR IOC
has been declared.
MCCs that are only LEOSAR/GEOSAR-capable are required to forward MEOSAR alert data
received from other MCCs to their SPOCs and RCCs.
Although all Cospas-Sarsat activities would continue to fall under the ICSPA, the Cospas-
Sarsat Parties should progress on the development of a follow-on international agreement, as
necessary.
All Cospas-Sarsat Participants should be involved during the IOC phase and encouraged to
implement MEOLUTs and MCCs as required to complete the MEOSAR system global
coverage and data distribution.
10.6
Full Operational Capability (FOC)
Full operational capability is a declaration by Cospas-Sarsat that the MEOSAR system should be
considered fully operational. At FOC the MEOSAR system should satisfy all requirements
defined by Cospas-Sarsat, including MEOSAR QMS requirements which includes those
contained in document C/S A.003. This implies that sufficient space and ground segment
components have been commissioned in accordance with Cospas-Sarsat requirements.
Before the MEOSAR system is declared at FOC the appropriate programmatic commitments must
be in place. Specifically, agreements must have been completed which commit MEOSAR space
segment providers to the long-term provision of MEOSAR space segment capabilities.
The number of satellites required to reach FOC is the minimum number of satellites that
provide the required level of performance (e.g. availability). In addition, a ground segment
that provides global coverage is necessary.
It should be noted that at FOC the MEOSAR system should provide near-instantaneous alerting
and locating services for existing 406 MHz beacons, therefore, it could be assumed that the
MEOSAR system could become the primary alerting source for 406 MHz beacons.
10-8
10.7
MEOSAR Implementation Schedule
Each MEOSAR constellation will be implemented in accordance with the plans developed by the
respective MEOSAR space segment provider. The tentative time line of MEOSAR
implementation is at Annex I.
Action Item 10.1:
Cospas-Sarsat and MEOSAR providers should develop proposals for the
content and implementation of MEOSAR Demonstration and Evaluation Programmes.
Action Item 10.2:
Cospas-Sarsat and MEOSAR providers should develop proposals in respect
of MEOSAR system requirements necessary for progressing to IOC.
Action Item 10.3:
MEOSAR providers should update the implementation schedules for their
MEOSAR constellations.
- END OF SECTION 10 -
ANNEXES TO COSPAS-SARSAT
406 MHz MEOSAR IMPLEMENTATION PLAN
A-1
ANNEX A
LIST OF ABBREVIATIONS, ACRONYMS AND DEFINITIONS
A.1
ABBREVIATIONS AND ACRONYMS
C/No
Carrier to noise density ratio
C/S R.0\#\#
Cospas-Sarsat System document in the R (Reports / Plans) series
C/S T.0\#\#
Cospas-Sarsat System document in the T (technical) series
CSCG
Cospas-Sarsat Coordinating Group (superseded by the Cospas-Sarsat Council)
D&E
Demonstration and Evaluation test
DASS
Distress Alerting Satellite System
EC
European Commission
EIRP
Effective Isotropically Radiated Power
ESA
European Space Agency.
EWG
Cospas-Sarsat Experts Working Group
FDOA
Frequency Difference Of Arrival
FLAM
Forward Link Alert Message
FOA
Burst frequency measured at the time of arrival (TOA)
FOC
Full Operational Capability
Galileo
A global navigation satellite system being developed by ESA and the EC
GJU
GALILEO Joint Undertaking
GEOSAR
Geostationary Satellite System for Search and Rescue
Glonass
A global navigation satellite system provided and operated by Russia
GMS
Galileo Mission Segment
GNSS
Global Navigation Satellite System
GOES
Geostationary Operational Environmental Satellite operated by the USA
GPS
Global Positioning System (global navigation satellite system operated by the
USA)
ICSPA
International Cospas-Sarsat Programme Agreement
IOC
Initial Operational Capability
IOV
In-Orbit Validation
ITU
International Telecommunication Union
JC
Joint Committee
kHz
kilohertz
LEOSAR
Low-altitude Earth Orbiting satellite System for Search and Rescue
LHCP
Left Hand Circular Polarisation
LUT
Local Users Terminal (ground station in the Cospas-Sarsat System for tracking
and processing the downlink of search and rescue satellites)
MCC
Mission Control Centre (control centre in the Cospas-Sarsat System for
distributing Cospas-Sarsat SAR distress alert messages)
A-2
MEOLUT
LUT in the MEOSAR system
MEOSAR
Medium-altitude Earth Orbiting satellite System for Search and Rescue
MHz
Megahertz
MIP
MEOSAR Implementation Plan
MQPSK
Mixed Quaternary Phase-Shift Keying
MSG
Meteosat Second Generation Satellite
MSS
Mobile Satellite Service
POC
Proof Of Concept
QPSK
Quaternary Phase-Shift Keying
RCC
Rescue Coordination Centre
RHCP
Right Hand Circular Polarisation
RLM
Return Link Message
RLS
Return Link Service
RLSP
Return Link Service Provider
SAR/BDS
Search and Rescue distress alerting service supported by the BeiDou satellite
System
SAR/Galileo
Search and Rescue distress alerting service supported by the Galileo satellite
System
SAR/Glonass
Search and Rescue distress alerting system using the Glonass satellites
SAR/GPS
Search and Rescue distress alerting service supported by the GPS III Block B &
C satellite System
SAR
Search and Rescue
SARP
Search and Rescue Processor
SARR
Search and Rescue Repeater
SIS
Signal In Space: navigation signal broadcast by Galileo satellites
SPFD
Spectral Power Flux Density
SPOC
SAR Point Of Contact
STB
Set of Transponded Bursts
TDOA
Time Difference Of Arrival
TG
Task Group
TOA
Time Of Arrival (Beacon burst time of arrival at the MEOSAR satellite)
TT&C
Telemetry, Tracking and Control
XML
Extensible Markup Language
A-3
A.2
DEFINITIONS
The following standard terminology should be used for the description of the MEOSAR
Ground Segment
MEOLUT
Antennas, hardware and software required to track global navigation satellite system (GNSS)
satellites, process and generate locations for 406 MHz distress beacons and distribute resultant
alerts to a Mission Control Center (MCC).
Dependent MEOLUT
MEOLUT with one or more antennas, which may or may not be co-located, that must
rely on data from another MEOLUT in order to generate independent locations.
Stand-Alone MEOLUT.
MEOLUT with multiple antennas, which may or may not be co-located, that does not
rely on any other MEOLUT or antenna(s) to generate independent locations, and may
share data with other MEOLUTs to improve performance.
MEOSAR Solution
An unambiguous location generated by a MEOLUT from one or more MEOSAR beacon
events.
Remote Antenna(s)
Antenna(s) that track global navigation satellite system (GNSS) satellites and recover beacon
messages, but do not generate locations for 406 MHz distress beacons. Remote antennas can
be used to enhance the capability of a MEOLUT, or can provide additional data to a MEOLUT
with insufficient stand-alone capability. Remote antennas have the same capabilities as
collocated antennas, but are geographically separated by a significant distance from the
MEOLUT processor.
Beacon Burst
A specific transmission from a beacon compliant with C/S T.001.
A beacon burst can be either short or long and is repeated periodically. The digital message
transmitted by the beacon can vary between consecutive beacon bursts, e.g. if the encapsulated
beacon location changes. The repetition period is much longer than the burst duration for both
short and long beacon bursts.
A-4
Figure A-1: Proposed MEOSAR terminology
Transponded Burst
A specific beacon burst as relayed by a single MEOSAR satellite.
A transponded burst may or may not be received by a MEOLUT depending on whether the
corresponding MEOSAR satellite is also visible from the MEOLUT location and whether a
MEOLUT antenna is allocated to that satellite.
Received Transponded Burst
A specific beacon burst as relayed by a single MEOSAR satellite and received through a single
MEOLUT antenna.
A received transponded burst is uniquely identified by: beacon ID, time of transmission,
satellite ID and antenna ID.
Set of Transponded Bursts (STB)
All transponded bursts corresponding to a single beacon burst (relayed through all MEOSAR
satellites within view of the beacon).
The transponder burst in an STB may be received by different MEOLUTs, depending on the
location of the beacon and the MEOLUTs and the corresponding satellites in common view.
MEOLUT
not received
echo
echo
STS
MEOSAR satellites
beacon
beacon
burst
received echo
received
STS
Transponded burst
Transponded burst
STB
Received Transponded burst
Beacon
Beacon
burst
Received
STB
Not received
Transponded burst
MEOSAR SATELLITES
MEOLUT
A-5
Received STB
All transponded bursts corresponding to a single beacon burst and received at a given
MEOLUT.
The received STB is a subset of the STB for the particular beacon burst. The number of
transponded bursts in the received STB is limited by the number of MEOLUT antennas and by
the number of satellites in common view of the beacon and the MEOLUT.
- END OF ANNEX A -
B-1
ANNEX B
PRELIMINARY DASS TRANSPONDER CHARACTERISTICS(1)
Parameter
Requirement
Units
Uplink frequency range
406.0 to 406.1
MHz
Nominal input power level at antenna input(2)
-159.0
dBW
Maximum input power level at antenna input (3)
-148.0
dBW
System dynamic range
dB
Receive antenna polarization
RHCP
-
Receive antenna gain
10.7
dBiC
System noise temperature
K
Receive system G/T
-17.7
dBi/K
Bandpass Characteristic (0.5 dB bandwidth)
KHz
Phase linearity (overall in-band)
within 10 of linear
Degrees
Group delay
5.8 +/- 0.5
us
Group delay slope
-
-
AGC time constant
[250]
ms
AGC dynamic range
dB
Transponder gain (including ant. gains)
dB
Transponder linearity (C/I)
-
-
Frequency translation
direct
-
Gain stability
+/- 0.5
dB
Output frequency stability
~1 x 10-11
-
Downlink frequency band
1544.8 to 1545.0
MHz
Downlink antenna polarization
RHCP
-
Maximum transmitter output power
dBW
Downlink antenna gain
10.5
dBiC
(1)
Final parameters for the DASS L-Band transponder will be supplied at completion of
instrument specification and design.
(2)
Four simultaneous 406 MHz beacon signals at the antenna input each at –165 dBW.
(3)
Ten simultaneous 406 MHz beacon signals at the antenna input each at –165 dBW
plus 2 interferers in the band each with 100 Watt EIRP.
- END OF ANNEX B -
C-1
ANNEX C
PRELIMINARY SAR/GALILEO TRANSPONDER CHARACTERISTICS (1)
Parameter
MIP Requirement
GALILEO IOV
Units
Uplink frequency range
406.0 to 406.1
406.0 to 406.1
MHz
Receive centre frequency
Normal mode
Narrowband mode
406.050
406.043
406.050
406.043
MHz
Nominal input power at antenna
-159.0
-
dBW
Maximum input power at antenna
-148.0
- 153.0
dBW
System dynamic range
dB
Receive antenna polarisation
RHCP
RHCP
Receive antenna gain at EoC (2)
dBi
Receive antenna axial ratio
< 2.5
1.8
dB
Receive antenna G/T (3)
At edge of coverage (2)
At centre of coverage
-17.7
-15.2
-13.5
dB/K
System noise temperature (3),(4)
K
Bandpass characteristics
Normal mode
Narrowband mode
> 80 kHz (1.0 dB)
> 90 kHz (3.0 dB)
< 110 kHz (10 dB)
< 170 kHz (45 dB)
< 200 kHz (70 dB)
> 50 kHz (1.0 dB)
< 75 kHz (10 dB)
< 130 kHz (45 dB)
< 160 kHz (70 dB)
> 80 kHz (1.9 dB)
> 90 kHz (2.5 dB)
< 110 kHz (8.5 dB)
< 170 kHz (64 dB)
< 200 kHz (67 dB)
> 50 kHz (1.1 dB)
< 75 kHz (16 dB)
< 130 kHz (53 dB)
< 160 kHz (55 dB)
Phase linearity (overall in-band)
Normal mode
Narrowband mode
/
/
°
Group delay (turn-around time) (5)
Normal mode
Narrowband mode
/
/
27 - 41
38 - 54
s
Group delay uncertainty (95% conf.)
< 190
ns
Group delay over 4 kHz (6) (slope)
Normal mode
Narrowband mode
s/4kHz
C-2
Transponder gain modes
Fixed Gain (FG)
ALC
ALC time constant
< 80
ms
ALC dynamic range
> 30
dB
Transponder gain
> 180
165 - 203
dB
Fixed gain mode adjustment range
(FGM: -1… +30)
dB
Gain setting for nominal o/p power
160 (FGM: 20)
dB
Transponder linearity (C/I3)
> 30
dBc
Translation frequency
1,138,050,000.0
Hz
Frequency translation
Accuracy
Short term stability (100ms)
±2 x 10-11
1 x 10-11
high: > ±2x10-11
2x10-11
(8)
(9)
Gain variation (7)
0.3
dBpk-pk
Translation frequency stability
high
(8)
Downlink frequency band
1,544.0 to 1,544.2
MHz
Downlink centre frequency
Normal mode
Narrowband mode
1,544.100
1,544.093
MHz
Downlink antenna polarisation
LHCP
Transmit antenna axial ratio
1.7
dB
Downlink EIRP (10)
> 18.0
dBW
EIRP stability in ALC mode
0.3
dBpk-pk
EIRP stability in FG mode
1.5
dBpk-pk
(1) These are the characteristics and typical performance parameters of SAR Transponders on
two Galileo satellites of the In-Orbit Validation (IOV) block. Characteristics of transponders
on satellites of the next block (FOC-1) shall be reported separately.
(2) The receive antenna edge of coverage (EoC) is defined as the edge of visible Earth, i.e.
beacon elevation angle of 0°.
(3) Assuming antenna external noise temperature Ta = 400 K.
(4) System temperature computed at transponder input.
(5) The full characterisation of each launched SAR payload with respect to delay will be
reported in tabular form.
(6) In the 1dB band.
(7) Gain variation in any 3 kHz within the operating band.
(8) The long-term translation frequency stability and accuracy are very high, as it is derived
from the navigation clocks on board.
(9) Depending on the configuration settings of the on-board clocks may be significantly better.
(10) In ALC mode or in FGM at nominal gain setting, over full Earth disc, including pointing
error.
- END OF ANNEX C -
D-1
ANNEX D
SAR/GLONASS REQUIREMENTS AND PRELIMINARY TRANSPONDERS’
CHARACTERISTICS
Parameter
MIP Requirement
SAR/GLONASS-K1
Units
Uplink frequency range
406.0 to 406.1
406.0 to 406.1
MHz
Receive centre frequency (1)
Normal mode
Narrowband (optional) mode
406.050
406.043
406.050
406.043
MHz
Nominal input power level at antenna
-160.0
dBW
Maximum input power level at antenna
-140.0
dBW
System dynamic range (1)
30.0
30.0
dB
Receive antenna polarisation (1)
RHCP
RHCP
Receive antenna gain
dBi
Receive antenna axial ratio (1)
< 2.5
TBD
dB
Receive antenna G/T At edge of coverage
-17.7
-16.7
dB/K
System noise temperature
K
Receive bandwidth(1):
Normal mode (1 dB)
≥ 90 kHz (1 dB)
≤ 100-120 kHz (10 dB)
≤ 170 kHz (40-45 dB)
≤ 210 kHz (50-70 dB)
Narrowband mode (1 dB)
> 50 kHz (1 dB)
< 75 kHz (10 dB)
< 130 kHz (45 dB)
< 160 kHz (50-70 dB)
Normal mode:
≥100 kHz (l dB)
≤ 160 kHz (10 dB)
≤180 kHz (20 dB)
≤ 215 kHz (30 dB)
Narrowband mode:
> 60 kHz (l dB)
< 82 kHz (10dB)
< 110 kHz (20 dB)
< 180 kHz (30 dB)
kHz
Phase linearity (overall in-band)
-
Not available
degree
Group delay (total turn-around time)
TBD
s
Group delay uncertainty (with 95% confidence)
< 500
< 100
ns
Group delay slope
(over any 4kHz in the 1dB band)
< 10
Normal mode: < 10
Narrowband mode: < 10
s/4 kHz
System (transponder) dynamic range (1)
> 30
> 30.0
Transponder gain modes
AGC
AGC
AGC
AGC time constant(1)
< 80
< 80
ms
AGC dynamic range(1)
> 30.0
> 30.0
dB
Transponder gain
> 175
> 175
dB
Transponder linearity(1)
> 30.0
> 30.0
dBc
Frequency translation, direct
(non-inverting), both modes
direct
direct
Frequency translation accuracy
± 2x10-11
–1.53x10-9
GHz
Frequency translation stability
(short term over 100 ms)
< 1x10-11
± 5x10-12
Rx to Tx conversion(1)
Frequency translation,
non-inverted
Non-inverted
Gain stability over temperature, frequency and
lifetime
-
2.0
dB pk-pk
Output frequency stability
High
High, derived from
navigation clock
Downlink frequency band
1544.80 to 1545.00
1544.85 to 1544.95
MHz
D-2
Downlink centre frequency
Normal mode
Narrowband mode
-
-
1544.900
1544.893
MHz
Downlink antenna polarization
Circular (RHCP or LHCP)
LHCP
Transmit emission mask (1)
Annex I of C/S T.014
TBD
Downlink EIRP (within +/- 14 deg off-nadir angle,
i.e. 10 deg elevation)
> 15
dBW
Note: (1) Interoperability parameter per Annex F.
- END OF ANNEX D -
E-1
ANNEX E
MINIMUM PERFORMANCE REQUIREMENTS FOR MEOSAR COMPATIBILITY
WITH THE 406 MHz COSPAS-SARSAT SYSTEM
The table provided below defines the minimum performance requirements that should be
satisfied by a MEOSAR system at full operational capability (FOC) to ensure compatibility
with the existing 406 MHz Cospas-Sarsat satellite system. It is understood that:
a)
these minimum requirements should be satisfied under nominal conditions, in particular
assuming that the 406 MHz beacon transmissions satisfy the specification of document
C/S T.001; and
b)
a MEOSAR satellite system at full operational capability may exhibit better performance
than the requirements specified below.
The table provides:
-
in column 1:
the performance parameter that characterises a specific system
capability;
-
in column 2:
the applicable requirement that would ensure compatibility with the
existing Cospas-Sarsat 406 MHz system;
-
in column 3:
the definition of the performance parameter;
-
in column 4:
applicable comments as necessary; and
-
in column 5
the applicable Cospas-Sarsat document reference in respect of the
identified requirement.
E-2
Performance
Parameter
Requirement
Definition
Comments
Reference
Detection Probability
99%
The probability of detecting the
transmission of a 406 MHz beacon and
recovering at the MEOLUT a valid
beacon message, within 10 minutes
from
the
first
beacon
message
transmission.
The MEOLUT referred to in
the definition is a function,
independent
of
its
actual
implementation, which may
include
several
distinct
physical
entities/facilities
operating in a network.
Detection probability for a single
LEO satellite pass in visibility
> 98% (C/S G.003). Detection
probability
over
successive
LEOSAR satellite passes > 99%.
GEOSAR detection probability
> 98%
within
min.
(C/S T.012).
Independent Location
Probability
98%
The probability of obtaining at the
MEOLUT a 2D location (Lat./Long.),
independently of any encoded position
data in the 406 MHz beacon message,
within 10 minutes from the first beacon
message transmission.
Same as above.
Cospas-Sarsat system exercises
have demonstrated a Doppler
location probability of 98% on a
single LEO satellite pass (C/S
G.003).
Independent Location
Error
P(e < 5 km)
> 95%
The
system
independent
location
solution should be within 5 km from the
actual beacon position 95% of the time.
This requirement applies to all
independent location solutions.
C/S T.002 requires 95% of
nominal solutions to be within
5 km from the actual position.
Estimated Error
(Error Ellipse)
50%
A measure of the accuracy of the
calculated
independent
location
expressed as an area that encompasses
the actual beacon location 50% of the
time.
This requirement applies to all
independent location solutions
provided by the system.
C/S
T.002
defines
the
requirement for a 50% error
ellipse.
E-3
Performance
Parameter
Requirement
Definition
Comments
Reference
Sensitivity
BER < 5x10-5
Assuming a nominal background noise
temperature of 6000K, the overall link
budget should provide a bit error rate
better than 5x10-5 to allow for adequate
system performance margins.
This BER is used in the analysis
for all repeater based system
protection
requirements
in
document C/S T.014.
Availability
99.5%
The system should be available
99.5% of the time over a period of one
year. The system is considered to be
unavailable
when
any
of
the
performance requirements listed in
this Table cannot be satisfied.
This goal may be achieved
through various means, i.e. by
providing
adequate
redundancies
and/or
high
reliability of sub-systems.
C/S A.005 requires a 99.5%
availability
of
Cospas-Sarsat
MCCs. The overall System
availability is achieved through
redundancy of the other sub-
systems.
Coverage
Global
The system should satisfy the minimum
performance requirements listed in this
Table regardless of the beacon position
on the Earth.
The
existing
Cospas-Sarsat
LEOSAR system provides global
coverage for 406 MHz beacons
(C/S G.003).
Capacity
3.8 M
The system minimum performance
requirements
should
be
satisfied
assuming
a
worldwide
406 MHz
beacon population of at least 3.8
million.
A
3.8
million
worldwide
beacon population corresponds
to a peak number of active
beacons in a MEO satellite
visibility area of 150. To be
confirmed upon completion of
MEOSAR
beacon
message
traffic model.
The existing LEOSAR system
has a maximum capacity of
3.8 million beacons when carrier
frequencies
are
spread
in
accordance with C/S T.012.
E-4
Performance
Parameter
Requirement
Definition
Comments
Reference
Processing Anomalies
< 1x10-4
The system should not produce more
than one processing anomaly for every
10,000 alert messages. A processing
anomaly is an alert message produced
by the system, which should not have
been generated, or which provided
incorrect information.
MCCs are required to validate
alert
messages
before
distribution to SAR services.
Processing anomalies may, or
may not result in false alerts.
This requirement applies to
Cospas-Sarsat LEO and GEO
LUTs
(C/S T.002
and
C/S T.009).
- END OF ANNEX E –
F-1
ANNEX F
MEOSAR SPACE SEGMENT INTEROPERABILITY PARAMETERS
Parameter
Requirement
Definition
Comments
Reference
SAR Receive Centre
Frequency (normal
bandwidth mode)
406.05 MHz
SAR Receive Bandwidth
(normal bandwidth mode)
> 80 kHz (1.0 dB bandwidth)
> 90 kHz (3.0 dB bandwidth)
< 110 kHz (10 dB bandwidth)
< 170 kHz (45 dB bandwidth)
< 200 kHz (70 dB bandwidth)
Normal mode must be included on
all satellite constellations.
The bandwidth characteristics
shall be centered at 406.05 MHz.
Optimises pass band to reduce the
possible impact from out of band
interferers.
Must satisfy system group delay
requirements.
SAR Receive Centre
Frequency (optional
additional bandwidth
mode)
406.043 MHz
SAR Receive Bandwidth
(optional additional
bandwidth mode)
> 50 kHz (1.0 dB bandwidth)
< 75 kHz (10 dB bandwidth)
< 130 kHz (45 dB bandwidth)
< 160 kHz (70 dB bandwidth)
The bandwidth characteristics shall
be centered at 406.043 MHz.
Narrowband option would provide
improved C/N, and reduce the
susceptibility to interference.
The 50 kHz covers channels A through
O, which is expected to satisfy capacity
requirements through 2025.
C/S T.012 traffic model
and 406 MHz Channel
Assignment Table.
Receive System G/T
> -17.7 dB/K
Measured at the input of the LNA.
Over the entire Earth coverage area.
Assuming an antenna noise of 400 K.
Axial Ratio
< 2.5 dB
Over entire Earth coverage area.
F-2
Parameter
Requirement
Definition
Comments
Reference
Rx Antenna Polarisation
RHCP
System Dynamic Range
> 30 dB
The linear range of the transponder,
not accounting for AGC.
Will accommodate 10 narrow band
signals (interferers or beacon bursts)
received at the satellite.
A nominal single beacon signal level at
the satellite receiver input is
approximately -165 dBW.
AGC Dynamic Range
> 30 dB
Required to accommodate varying noise
and interference levels.
AGC Time Constant
[< 80 ms]
Sarsat LEOSAR AGC
performance as documented
at Table 3.3 of document
C/S T.003.
SAR Transmit Frequency
SAR/Galileo
(1544.0-1544.2 MHz)
DASS and SAR/Glonass
(1544.8 - 1545.0 MHz)
The exact bandwidth used for the
downlink must take into account
protection requirements for other
instruments that have filed to use the
band.
Transmit EIRP
> 15 dBW
Over entire Earth coverage.
Downlink Polarisation
Circular
Either RHCP or LHCP.
SAR Transmit Emission
Mask
Must meet Annex I of
C/S T.014 and Inmarsat-E
protection requirements
Negotiations with Inmarsat will be
required to confirm their protection
requirements.
Annex I of C/S T.014
F-3
Parameter
Requirement
Definition
Comments
Reference
Repeater linearity (C/I)
> 30 dBc
Ratio of power to intermodulation
products (which occur when the
repeater operates beyond its linear
range)
Frequency Translation
Accuracy +/- 2x10-11
Short Term Stability (100 ms) <
1x10-11
Synchronisation with the on-board
navigation frequency reference provides
for a very accurate and stable frequency
translation on all MEOSAR satellites.
Allows FDOA measurements through
different satellites regardless of their
constellation.
SAR Rx to Tx conversion
Frequency Translation, non-
inverted
Rx band is not re-modulated on a
downlink carrier
Conversion may utilize an intermediate
frequency to facilitate translation with
minimum loss of gain.
Group Delay
< 10 µs / 4 kHz
Group delay is a function of bandwidth
and filter design. Filter must be designed
with group delay characteristics that
satisfy the system performance
requirements.
Group delay parameter is for guidance
only and should be considered subsidiary
to the Bandwidth requirement.
Group Delay Stability
< 500 ns
This performance will ensure that group
delay has negligible impact on TDOA
measurements
F-4
- END OF ANNEX F -
G-1
ANNEX G
PRELIMINARY MEOLUT INTEROPERABILITY PARAMETERS
Parameter
Requirement
Definition
Comments
Reference
MEOLUT BER Performance
Suitable to provide
BER of 5E-5
Achievable with a G/T of 4 dB/K
Update MIP to correct BER discrepancy
at Annex E.
Antenna Polarisation
RHCP and LHCP
DASS and SAR/BDS will operate with
RHCP downlinks, SAR/Galileo with
LHCP downlinks.
SAR/Glonass will operate with LHCP
downlinks.
MEOLUT System Clock
Accuracy
UTC +/- 50 ns
Time Tagging Accuracy
Standard Deviation
within 7 µs
Time tagging accuracy measured at
MEOLUT processing threshold
using a calibrated input signal fed
directly into the MEOLUT.
When processing C/S T.001 signals.
Theoretical limit at threshold is 3 µs.
Frequency Measurement
Accuracy
Standard Deviation
within 0.1 Hz
Frequency measurement accuracy at
MEOLUT processing threshold
using a calibrated input signal fed
directly into the MEOLUT.
To facilitate the exchange of frequency
measurements between MEOLUTs.
Theoretical limit at threshold is 0.025 Hz.
G-2
Parameter
Requirement
Definition
Comments
Reference
Processing Threshold
34.8 dB - Hz
C/No measured at the demodulator.
C/No that supports a BER of 5E-5.
Beacon Modulations
Supported
As per C/S T.001
New modulations are being considered to
enhance MEOSAR system performance.
When and if accepted these will be
included in C/S T.001.
Note:
The above MEOLUT interoperability parameters have not been finalised and may be amended as MEOLUT development proceeds.
- END OF ANNEX G -
H-1
ANNEX H
WORK PLAN FOR MEOSAR SYSTEM DEVELOPMENT AND INTEGRATION IN
RESPECT OF TECHNICAL AND OPERATIONAL MATTERS
This annex presents a work plan overview for the development and integration of the MEOSAR
system. The work plan is organized by system data flow; it presents the work required for each
process or interface and the Cospas-Sarsat body which should undertake the work effort. The
work effort in some cases can be accomplished during a single implementation phase, but in
others it can span several phases. The work plan must retain some measure of flexibility to
account for the different implementation schedules of the MEOSAR component providers. The
work plan overview is graphically depicted at Figure H.1.
H.1 Beacon to Satellite Interface
Because of the use of transparent repeaters planned for the MEOSAR satellite payloads, there
are no modifications required to the 406 MHz beacon for its compatibility with the proposed
MEOSAR system. However, the possible implementation of advanced capabilities of a return
link or enhanced beacon transmissions would require consideration by the Joint Committee and
Task Groups as required to study specific needs. Consideration of a return link service should
be accomplished as early as possible in the development and proof-of-concept/in-orbit
validation phases. Because of the use of spacecraft repeater instruments, enhanced beacon
characteristics can be considered at any time.
H.2 Satellite to MEOLUT Interface
The satellite to MEOLUT interface, or the satellite downlink parameters, must be completed
in the development phase. To this end, the major parameters for downlink compatibility and
interoperability have been agreed among the MEOSAR system providers and are documented
in section 6 and Annex F of this document. Issues remaining to be completed should be
addressed in specific Experts’ Working Groups established by the Council, with the results
recorded in this document according to procedures given in section 1.3.
H.3 MEOLUT Processing
The development of MEOLUT processing will initially be accomplished by the respective
MEOSAR component providers. The performance of the prototype MEOLUTs will be
evaluated during the proof-of-concept/in-orbit validation phase. Further evaluation of the
MEOLUTs will be accomplished during the demonstration and evaluation phase, and the
MEOSAR D&E Plan should include the necessary test objectives to be measured. These
evaluations will contribute to the effort within Cospas-Sarsat to develop new System
documents for MEOLUT performance, design guidelines, and commissioning. The
development of these documents should be accomplished by the Joint Committee, with Task
Groups as necessary, and should be completed and approved by the end of the demonstration
and evaluation phase.
H-2
H.4 MEOLUT to MCC Interface
There are no explicit actions to be taken in respect of the MEOLUT to MCC interface as
Cospas-Sarsat does not create specifications dealing with this nominally technical matter of
ground segment provider concern. However, the appropriate body of the Joint Committee
should ensure that the necessary data fields to be provided by the MEOLUTs are specified in
the operational documents. The Joint Committee should continue to look at changes that need
to be made to existing System documents and ensure that the MEOSAR D&E Plan includes
the appropriate references to MEOLUT / MCC interface, as necessary.
H.5 MCC Processing
A significant effort is required to determine how MEOSAR alert data will be incorporated into
the distress alert information distributed to the SAR services. The amount of modifications
necessary in the Cospas-Sarsat MCCs will depend on the operational scenario concept
developed for the use of MEOSAR data, and the additional information provided by the
MEOSAR system. Extensive modifications will require the convening of a dedicated task
group to review the impact on the documents C/S A.001 (DDP) and C/S A.002 (SID), and to
recommend the necessary updates. Modification will also be required to ancillary documents
such as C/S A.003 (monitoring and reporting), but these may be accomplished within the
context of the Joint Committee. The Joint Committee should ensure that the MEOSAR D&E
Plan accommodates the necessary objectives to evaluate the MCC performance.
H.6 MCC to RCC/SPOC MEOSAR Alert Data Distribution
The MEOSAR D&E implementation phase offers the opportunity to evaluate the planned data
distribution procedures for MEOSAR distress alert data, and the anticipated response
procedures for the use of the data by SAR services. The Joint Committee, and possibly a
dedicated task group, will need to ensure that the operational procedures and message formats
are modified as necessary to optimise the availability of MEOSAR data. This will particularly
impact the document C/S A.002 (SID) and other ancillary documents provided for RCC/SPOC
edification on the use of Cospas-Sarsat alert data. Cospas-Sarsat will need to coordinate with
the appropriate international organizations to ensure that their publications are updated to
include the most current description of the System.
H.7 Return Link Service
If a return link service is implemented by any MEOSAR component provider, it will represent
a new function that will, in all probability, impact on several, or all, interfaces and processes
within the Cospas-Sarsat System, depending on its operational implementation. The return
link function may be implemented by entities outside the Cospas-Sarsat System, or may be part
of Cospas-Sarsat, but in either case its implementation must be recognised and accommodated
by the System. Because it represents an entirely new operational concept, the introduction of
a return link process should first be studied in dedicated operational / technical task groups,
given adequate guidance by the Council on the scope of their efforts. The impact of a return
link service on the processes and interfaces covered in the preceding sections will not be known
H-3
until an operational scenario is developed by Cospas-Sarsat task groups, in coordination with
the MEOSAR component providers and, possibly, national Administrations. Any impact on
the Cospas-Sarsat System must be documented in the appropriate System documents. The
development of a return link service could impact all phases of MEOSAR system
implementation.
H-4
Technical / Operational
Matter
Beacon to Satellite
Interface
Satellite to MEOLUT
Interface
MEOLUT Processing
MEOLUT to MCC
Interface
MCC Processing
MCC to SPOC/RCC
Alert Distribution
Description
No change to current
beacon specifications;
review return link
service
Development of
downlink parameters
and issues regarding
interoperability
Development of
design and
performance
specifications
Development of
specifications
Change to
specifications and
data distribution
Changes to alert
message format and
content
Venue
N/A
EWG
JC / TG
JC / TG
JC / TG
JC / TG
System Documentation
Affected
N/A
C/S R.012 (MIP)
D&E Plan; New
documents; affected
System documents
D&E Plan; affected
System documents
D&E Plan;
C/S A.001;
C/S A.002; affected
System documents
Affected System
documents;
documents of
international bodies
Return Link
Discussed in JC / TG
and may affect several
System documents
TBD
TBD
TBD
TBD
TBD
Figure H.1:
Summary of Work Plan for Technical and Operational Matters
- END OF ANNEX H –
MEOLUT
MCC
SPOC / RCC
I-1
ANNEX I
TENTATIVE TIME LINE OF MEOSAR IMPLEMENTATION
- END OF ANNEX I -
J-1
ANNEX J
SAMPLE MEOSAR CONSTELLATION LINK BUDGET
System Constants
Units
Value
Comments
Boltzman's Constant
Joules/K
1.38E-23
Boltzman's Constant
dB(W/m2Hz)
-228.6
Satellite Altitude - from earth centre
km
29994.135
23,616 km above earth surface
Earth Radius
km
6378.135
Parameter
Units
Typical
Case
Uplink (Beacon to Spacecraft)
Beacon Transmit Power
dBW
7.00
Beacon spec C/S T.001 para 2.3.2
Nominal power 5 Watts
Beacon Antenna Gain
dB
0.00
Beacon spec T.001 para 2.3.3, approx
mid-range case
Elevation
deg
30.0
Typical elev to a MEOSAR satellite
Range
Km
Slant range at 30 degree elevation
Uplink Frequency
MHz
406.050
Middle of beacon operating band
Path Loss
dB
-173.0
Polarization Loss
dB
-4.5
Linear beacon antenna to elliptical
spacecraft antenna
Fading loss
dB
-2.5
Sum of various atmospheric effects
G/T of Satellite Rx Antenna
dB/K
-17.7
Estimated value
Uplink C/No
dBHz
37.9
Downlink (Spacecraft to MEOLUT)
Scenario 1 Scenario 2 Two possible scenarios for satellite to
MEOLUT link
Satellite Transmit EIRP
dBW
15.0
20.0 Two possible scenarios for satellite
Elevation
deg
Range
Km
Downlink Frequency
MHz
1544.5
1544.5 Mid-band for 1544.0 to 1544.1 MHz
Path Loss
dB
-184.6
-184.6
Fading Loss
dB
-1.0
-1.0
Polarization Loss
dB
-1.0
-1.0 LUT antenna will need to match
polarization of spacecraft D/L antenna
Power Sharing Loss
dB
-10.0
-10.0 Assume 8 total signals + 1 dB for noise
Ground Station G/T
dB/degK
4.0
-1.0 Two possible scenarios for MEOLUT
Downlink C/No
dBHz
51.0
51.0
Estimated downlink C/Io
dBHz
51.0
51.0
Downlink C/(No+Io)
dBHz
48.0
48.0
Overall C/(No+Io)
dBHz
37.4
37.4 Combined effect of uplink and downlink
Required C/No
Theoretical Eb/No for required BER
dB
8.8
Theoretical for BPSK at 5x10-5 BER
Beacon Data Modulation loss (for 1.1rad) dB
1.0
Due to Bi-phase-L being used in
beacon, relative to BPSK
Coding Gain
dB
2.0
from BCH decoding on beacon burst
Processing Gain (on only 1 burst)
dB
0.0
For decoding beacon on 1 burst with no
integration
Modem implementation loss
dB
1.0
Required Eb/No on coded channel
dB
8.8
Bit rate (at 400 bps)
dBHz
26.0
Required C/(No+Io)
dBHz
34.8
Margin
dB
2.6
J-2
Summary:
The link budget is calculated for a single burst from a 406 MHz beacon at nominal power (5 W)
transmitting to a MEOSAR satellite at a 30 degree elevation angle, and the MEOLUT is
viewing that single satellite also at a 30 degree elevation angle. It is assumed that there are a
total of 8 signals present simultaneously in the band.
The resultant values for this link budget are:
(C/No)up = 37.9 dBHz
(C/No)down = 48.0 dBHz (i.e. 10 dB above the (C/No)up)
(C/No)overall = 37.4 dBHz
(C/No)required = 34.8 dBHz
Margin = 2.6 dB
This (C/No)down can be achieved with a satellite EIRP of 15 to 20 dBW, requiring a MEOLUT
antenna G/T greater than 4 or –1 dB/K, respectively.
Based on the assumptions adopted for the link budget calculations, MEOSAR interoperability can
be achieved with a MEOLUT G/T of 4 dB/K and MEOSAR satellite downlinks with an EIRP of
15 dBW. Under these conditions MEOSAR system communication links would provide 2.6 dB
of margin.
- END OF ANNEX J -
K-1
ANNEX K
LIST OF ACTIONS
FOR THE DEVELOPMENT AND INTEGRATION
OF A MEOSAR SYSTEM INTO COSPAS-SARSAT
Action
Status / Comments
Action Item 2.1: MEOSAR providers should develop link
budgets for their respective MEOSAR satellite constellations for
inclusion in future revisions of this document. The link budgets
should conform to the assumptions and format adopted for the
sample link budget provided at Annex J.
Revision provided for
SAR/Glonass
To be continued
Action Item 2.2: MEOSAR
providers
should
update,
as
necessary, the information concerning the design, performance,
and functionality of their system.
On-going
Action Item 5.1: MEOSAR providers are invited to conduct
analysis to identify performance levels that can be achieved
practically. The analysis should particularly investigate the beacon
to satellite and satellite to MEOLUT link budgets, and their impact
on various aspects of overall MEOSAR system performance.
On-going
Action Item 5.2: MEOSAR providers are invited to conduct
analysis to identify anticipated MEOSAR location determination
performance in respect of location accuracy and time to produce
location information, and to propose options for optimising
MEOSAR location determination performance.
On-going
Action Item 5.3: MEOSAR providers and Cospas-Sarsat are
invited to develop a MEOSAR capacity model, and proposals for a
406 MHz channel assignment strategy that accommodates
LEOSAR, GEOSAR and MEOSAR requirements.
Open
Action Item 5.4: Cospas-Sarsat Participants are invited to:
a. investigate whether their respective Administrations operate, or
have knowledge of other Administrations which operate wind
profiler radars at 404.3 MHz, and report their findings to the
Council; and
b. request administrations operating wind profilers at 404.3 MHz
to move these radars to the 449 MHz frequency band.
On-going
Modifications of US
profiler radar transmitters
is in progress with three
transmitters modified each
year.
K-2
Action
Status / Comments
Action Item 6.1: MEOSAR providers should:
a. consider the protection requirements for the other systems that
have notified their use of the 1544 – 1545 MHz band when
designing their MEOSAR downlinks;
b. conduct investigations to identify other systems that have, or
will have, started the coordination / notification process with
the ITU prior to the respective MEOSAR provider, and
consider the protection requirements for such systems when
designing MEOSAR downlinks; and
c. initiate the formal ITU advance publication, coordination and
notification process for their MEOSAR satellite network, in
accordance with the procedures described in the Radio
Regulations.
On-going
Notification of
SAR/Glonass frequencies
has been made, Status of
notification for
SAR/Galileo frequencies
to be investigated by
France/ESA
Action Item 6.2: MEOSAR providers should study the issue of
how many DASS and SAR/Glonass MEOSAR repeaters could be
accommodated in the upper portion of the band without generating
harmful interference to each other.
On going
Action Item 6.3: The
Secretariat
should
forward
any
information regarding Koreasat downlink provided by Korea to the
MEOSAR providers.
No information received
from Korea
Action Item 6.4: MEOSAR providers should:
a. establish susceptibility / protection requirements for their
MEOSAR downlinks; and
b. consider the possible interference from other systems,
including inter MEOSAR satellite constellation interference,
when designing their downlinks, and confirm whether the
minimum performance required for compatibility with Cospas-
Sarsat would still be satisfied while operating in the presence
of interference from these systems.
Open
Action Item 6.5:
MEOSAR providers should conduct
analyses for inclusion in future revisions of this document, to refine
the MEOSAR payload requirements provided at Annex F for
enabling MEOLUTs to receive and process the downlink signals
from multiple MEOSAR satellite constellations.
Open
Action Item 7.1:
Cospas-Sarsat
Participants
should
investigate, through trials where possible, the operational benefits
and drawbacks that may be associated with distress alert
acknowledgement services and return link services that control
beacon transmissions.
Open
Action Item 7.2:
Cospas-Sarsat Participants and MEOSAR
providers should conduct analysis to identify suitable options for
operating and managing acknowledgement services.
Open
K-3
Action
Status / Comments
Action Item 7.3:
Cospas-Sarsat Participants and MEOSAR
providers
should
develop
technical
proposals
for
acknowledgement services (including description of the required
downlink signals and 406 MHz beacon specification / type
approval requirements).
Open
Action Item 7.4: Cospas-Sarsat and MEOSAR providers should
conduct analysis to identify improvements to the 406 MHz beacon
specification for the MEOSAR system. The following points
should be specifically addressed:
a. changes in the channel coding (e.g. convolutional coding);
b. the impact that new beacon specifications would have on
System capacity;
c. new modulation techniques to improve TDOA/FDOA
performance;
d. improvements to the message format;
e. additional encoded data requested by SAR authorities;
f. general optimisation of beacon parameters;
g. technologies that could reduce the cost of the beacon; and
h. the suitability of the MQPSK modulation for the MEOSAR
TDOA time-tagging requirement.
Open
Action Item 8.1: Cospas-Sarsat and MEOSAR providers should
conduct analysis on the feasibility of developing MEOLUTs and
identifying the associated LUT technical characteristics necessary
for simultaneously receiving and processing the downlinks from:
a. multiple MEOSAR satellites from the same MEOSAR
constellation; and
b. multiple MEOSAR satellites from different MEOSAR
constellations.
Open
Action Item 8.2:
Cospas-Sarsat and MEOSAR providers
should conduct analysis and propose options for a MEOLUT
ground segment architecture. The analysis should specifically
address advantages and disadvantages of networking MEOLUTs,
propose options for sharing MEOLUT beacon burst data
measurements with other MEOLUTs, and identify specification
and commissioning requirements for the MEOLUT data sharing
function.
Open
Action Item 8.3:
Cospas-Sarsat and MEOSAR providers
should conduct analysis and propose MEOLUT functional,
technical and commissioning requirements, that ensure that
MEOLUTs will be capable of providing a service that satisfies the
performance requirements identified at section 5.
Open
K-4
Action
Status / Comments
Action Item 9.1:
MEOSAR providers should conduct
studies and trials to identify:
a. what calibration information will be required to support
Cospas-Sarsat performance requirements;
b. the required update frequency of calibration information; and
c. the most appropriate methods for obtaining and distributing
calibration information.
Open
Action Item 10.1:
Cospas-Sarsat and MEOSAR providers
should develop proposals for the content and implementation of
MEOSAR Demonstration and Evaluation Programmes.
Open
Action Item 10.2:
Cospas-Sarsat and MEOSAR providers
should develop proposals in respect of MEOSAR system
requirements necessary for progressing to IOC.
Open
Action Item 10.3:
MEOSAR providers should update the
implementation schedules for their MEOSAR constellations.
On-going
- END OF ANNEX K –
L-1
ANNEX L
PRELIMINARY MEOLUT NETWORK ARCHITECTURE
AND BURST DATA REQUIREMENTS
This Annex illustrates the architecture concept for MEOLUT networking
L.1 MEOLUT NETWORK TOPOLOGY AND METHODOLOGY
Network topology refers to the physical connectivity between MEOLUT sites: examples
include mesh, star and ring configurations. The primary approach for exchanging data is a
partial mesh topology, involving point-to-point connections between MEOLUTs, as necessary
to provide connections to neighboring MEOLUTs
L.1.1
Primary Partial Mesh Topology
Figure L.1: Primary Topology of the MEOLUT Network
MCC
MCC
MEOLUT
MEOLUT
MCC
MEOLUT
MEOLUT
MCC
Location Data
Location Data
Location Data
Location Data
Optional Sharing of TOA/FOA Data Between MEOLUTS
(Established via bilateral arrangements between MEOLUT operators)
Two way data exchange
One way data exchange
L-2
L.1.2
Optional Data Exchange Methodology
As an option some MEOLUT providers may want to share measurement data with all
participating MEOLUTs while limiting the number of point to point connections. An example
of this is node forwarding methodology where forwarding of data received from other
MEOLUTs requires the preliminary step of the concatenation of the local MEOLUT data with
all data coming from other MEOLUTs. Forwarded MEOLUT FOA/TOA data shall not be
modified by the transit nodes. TOA/FOA data may be forwarded between MEOLUTs by the
applying the following conventions:
- the exchanged files shall be limited to a maximum number of [2000] TOA/FOA data
records (number to be implemented as a configurable value to allow possible future
adjustments);
- beyond the maximum number of records, the older records (based on TOA) shall be
removed from the TOA/FOA data file to be exchanged;
- TOA/FOA data files shall be pushed every [60] seconds (periodicity to be implemented
as a configurable value to allow possible future adjustment) by the MEOLUT to all linked
MEOLUTs. No accurate time synchronization shall be required; and
- possible duplicated TOA/FOA data records shall be removed.
L.1.3
Optional Central Server Node
An optional MEOLUT Central Data Server could be implemented within the primary partial mesh
topology of the MEOLUT network. MEOLUTs could store their data on the Central Data Server.
MEOLUTs could then obtain data from the central data server as desired.
L.2 MEOLUT TOA/FOA DATA EXCHANGE
Sharing of MEOSAR TOA/FOA data is optional, determined by national requirements and
arranged on a bilateral basis between MEOLUT operators. All TOA/FOA data shall include data
content and be transferred in the data format specified in Annex M. Data transfer shall use a
secure form of FTP as per the specifications found in Annex P. (Annex L is a place holder for a
future update to C/S A.001 (DDP) as Annexes M and P are place holders for future updates to
document C/S A.002 (SID)). Using shared data for location processing is optional.
L.3
MEOLUT TOA/FOA CENTRAL NODE
[definition required]
- END OF ANNEX L -
M-1
ANNEX M
DRAFT DEFINITIONS OF BURST DATA ELEMENTS
AND ASSOCIATED MESSAGE FIELDS DESCRIPTIONS
The following definitions and descriptions of data elements and message fields are provided in
accordance with the conventions / standards and formats used to define MCC interfaces in the
document C/S A.002 (SID), Annexes B and C. However, these definitions will not be included
in the Cospas-Sarsat System Document C/S A.002 (SID) at this stage.
New message fields 67 to 77, which are specific to MEOSAR burst data, are described per the
format used in Table B.1 of the SID and defined as per Appendix B.1 of Annex B to the SID.
Note: In this Annex, existing text in the document C/S A.002 (SID) is in normal fonts, deletions
are shown as strike out fonts and additions are in italic fonts.
M-2
TABLE B.1 TO ANNEX B OF C/S A.002 (SID)
MESSAGE FIELDS DESCRIPTION
MF# NAME
CONTENT
CHARACTER TEXT
REPORTING MCC
(see www.cospas-sarsat.int)
nnnn
FACILITY
SPACECRAFT ID
SARSAT
= 001 -> 099
nnn
COSPAS
= 101 -> 199
GOES
= 201 -> 220
LUCH-M
= 221 -> 240
INSAT-2, INSAT-3 = 241 -> 260
MSG
= 261 -> 280
GPS
= 300 -> 3991
Galileo
= 400 -> 499
GLONASS
= 500 -> 599
BDS
= 600 -> 699
(TBD at www.cospas-sarsat.int)
UPLINK TOA
YEAR = 00 -> 99
nn
DAY(JULIAN) = 001 -> 366
nnn
UTC - HRS = 00 -> 23
nnnn
MINS = 00 -> 59
SECS = 00.000000 -> 59.999999
nn.nnnnnn
UPLINK FOA (Hz)
406000000.000 -> 406100000.000
nnnnnnnnn.nnn
TIME OFFSET (sec)
0.000000 -> 9.999999
n.nnnnnn
DEFAULT VALUE = 0.000000
FREQUENCY OFFSET (Hz)
-90000.000 -> +90000.000
snnnnn.nnn
DEFAULT VALUE = +99999.999
ANTENNA ID
(TBD at www.cospas-sarsat.org)
nn
DEFAULT VALUE = 00
C/N0 (dBHz)
00.0 -> 99.9
nn.n
DEFAULT VALUE = 00.0
BIT RATE
000.000 -> 999.999
nnn.nnn
DEFAULT VALUE = 000.000
SPARE DATA
FFFF
hhhh
DEFAULT VALUE = 0000
SATELLITE POSITION (km)
X=-99999.9999 ->+99999.9999
(OPTIONAL)
DEFAULT VALUE = +00000.0000
snnnnn.nnnn
Y=-99999.9999 ->+99999.9999
DEFAULT VALUE = +00000.0000
snnnnn.nnnn
Z=-99999.9999 ->+99999.9999
DEFAULT VALUE = +00000.0000
snnnnn.nnnn
M-3
SATELLITE VELOCITY (km/s) X=-999.999999 ->+999.999999
(OPTIONAL)
DEFAULT VALUE = +000.000000
snnn.nnnnnn
Y=-999.999999 ->+999.999999
DEFAULT VALUE = +000.000000
snnn.nnnnnn
Z=-999.999999 ->+999.999999
DEFAULT VALUE = +000.000000
snnn.nnnnnn
FULL 406 MESSAGE
36 HEX CHARACTERS (BITS 1-144)
h..........h
(SEE C/S T.001)
1. For MEOSAR satellites the sequence within the range corresponds to the Pseudo Random Noise (PRN)
number for the spacecraft (e.g., GPS PRN 23 would be 323).
M-4
APPENDIX B.1 TO ANNEX B OF C/S A.002 (SID)
MESSAGE FIELDS DEFINITION
MF
Message Fields Definition
\#
2.
Reporting MCC Facility
The identification code corresponding to the MCCfacility (e.g., MCC, LUT) sending the
current message.
67.
Uplink TOA †
Time that the burst is received at the satellite as calculated by the MEOLUT. The time
reference point (anchor) of a 406 MHz SAR burst is the end of the 24th bit in the message
Preamble. The end of the 24th bit is defined as the mid point of the 50% phase crossing
(i.e. “zero-crossing”) of the mid-transitions of the 24th and 25th bit.
68.
Uplink FOA
Burst frequency measured at the time of the Uplink TOA.
69.
Time Offset †
This is the calculated difference in time between the reception of the beacon burst at the
satellite and the ground station. Adding this offset to the Uplink TOA provides the time
the burst was received at the ground station.
70.
Frequency Offset
This is the calculated difference of the burst frequency received by the satellite and the
burst frequency as estimated by the ground station. Adding this offset to the Uplink FOA
provides the frequency of the burst as estimated by the ground station in the 406 MHz
frequency band. If the offset is set to the default value, the Uplink FOA refers to the
frequency measured at the ground station (i.e. offset is included). The intended use of the
default value pertains to “antenna only” installations that may not have the capacity to
compute this offset.
71.
Antenna ID
The identification code corresponding to the individual antenna associated with the
ground station that originally provided the burst data being reported in the SIT message.
† If the offset is set to the default value, the Uplink TOA refers to the time the end of
bit 24 was received at the ground station (i.e. offset is included). The intended use of
the default value pertains to “antenna only” installations that may not have the capacity
to compute this offset.
M-5
72.
C/N0
The Carrier over Noise Density of the detected burst as determined by the ground station.
73.
Bit Rate
The number of bits per second as measured by the ground station.
74.
Spare Data
This field consists of four hexadecimal characters as place holders for additional
information.
75.
Satellite Position (Optional)
The X, Y and Z components of the satellite position with respect to the centre of the earth
in kilometres, in the earth-fixed co-ordinate system and in effect at the time specified by
MF\#67.
76.
Satellite Velocity (Optional)
The X, Y and Z components of the satellite velocity vectors with respect to the centre of
the earth in kilometres per second, in the earth-fixed co-ordinate system and in effect at
the time specified by MF\#67.
77.
Full 406 Message
The 406 MHz binary message of the solution, in its undecoded form, shown in the full 36
hexadecimal character representation.
M-6
ANNEX C OF C/S A.002 (SID)
MESSAGE CONTENT FOR MEOSAR DATA MESSAGES
The TOA/FOA data to be transferred between MEOLUTS is described by the Schema below in
Figure M.1. This XML Schema document can be copied to an appropriate folder on a local
MEOLUT data server for immediate use by any third-party XML parser. Note that each “element
name” corresponds to the message field name as provided in Annex B.1 of C/S A.002 (SID) or
the corresponding additions above in this Annex, with the explicit replacement of all spaces and
other punctuation characters by the underscore characters (“\_”).
M-7
Figure M.1 – XML Schema for the transfer of TOA/FOA data between MEOLUTs
M-8
APPENDIX C.1 TO ANNEX C OF C/S A.002 (SID)
SAMPLE MESSAGES
SAMPLE MESSAGE FOR
TOA/FOA XML DATA TRANSFER
312
7106
16
ADDFFFFFFFFFFFC
42BB1F56EFFFFFFFFFFFE5CB630000000000
10 272 0003 50.623698
406036073.075
0.076403
2255.694
37.6
400.046
0000
22797.7391 -13074.3953 -00794.0700
001.064675 002.052740 -003.157027
- END OF ANNEX M -
N-1
ANNEX N
POSSIBLE MEOSAR SYSTEM PERFORMANCE PARAMETERS
Parameter
Definition
Conditions of measurement
Comments
Valid Message
Throughput
Probability of detection of a valid, or complete, message
from a single beacon burst: the ratio of the number
valid/complete messages received via a single MEO
Channel over the expected number of bursts which should
have been received during a given period of time.
• Standard 406 MHz beacon
• BCN/Sat. elevation angle ≥ [5°]
• LUT/Sat. elevation angle ≥ [5°]
• Min sample size [TBD]
• To be determined for 5° elevation angle
increments
BCN/Sat elevation angle
and C/No should be
collected to characterise
performance.
Complete Message
Throughput
Single Channel Valid
Message Detection
Probability
Probability of detection of a valid/complete beacon message
via a single MEO channel over a given period of time after
[beacon activation] [first burst transmission].
Same as above, except for the time period.
The probability can be measured for periods
of 2, 5 and/or 10 minutes after [first burst
transmission] [beacon activation].
Single channel probabilities can be reported
as a function of the elevation angle using 5°
elevation angle increments.
2 minute = 2 bursts
5 minutes = 6 bursts
10 minutes = 12 bursts
The C/No of the channel
should be recorded.
Single Channel
Complete Message
Detection Probability
Multi channel
Detection Probability
Probability of detection of a valid [or complete] beacon
message by a MEOLUT using multiple channels over a
given period of time after [beacon activation] [first burst
transmission].
Short Message
Transfer Time
Time elapsed between beacon activation and the production
by a MEOLUT of the first valid message.
• Standard 406 MHz beacon
• BCN/Sat. elevation angle ≥ [5°]
• LUT/Sat. elevation angle ≥ [5°]
These times may be
affected by the distance of
the beacon to the
MEOLUT.
Long Message
Transfer Time
Time elapsed between beacon activation and the production
by a MEOLUT of the first complete message.
Confirmed Message
Transfer Time
Time elapsed between beacon activation and the production
by a MEOLUT of the second identical complete message.
Channel Threshold
Minimum C/No that allows the detection of a valid message
from a single burst over a single channel with [95%]
probability.
• Standard 406 MHz beacon
• Min sample size [TBD]
• To be determined for 5° elevation angle
increments
Average C/No of a MEO
channel could also be
useful to characterise the
achieved performance.
N-2
Parameter
Definition
Conditions of measurement
Comments
Single Burst
Independent Location
Probability
Probability of obtaining an independent 2D location
(Lat./Long.) using a single burst transmission, with a
location error less than [5] km.
• Standard 406 MHz beacon
• BCN/Sat. elevation angle ≥ [5°]
• LUT/Sat. elevation angle ≥ [5°]
• Sample size: ≥ TBD
• Distribution to be reported as a function
of HDOP and number of channels (i.e. 3,
≥4)
Number of MEO channels
and HDOP should be
reported.
Single Burst
Independent Location
Accuracy
Average location error for single burst independent 2D
locations from a given set of MEOLUTs with max HDOP of
[TBD].
Three MEO Channels
Independent Location
Probability
Probability of obtaining an independent 2D location
(Lat./Long.) within [10] minutes from [first burst
transmission] [beacon activation], with a location error less
than [5] km.
Standard beacon bursts relayed via
three/four or more MEO satellites to a given
MEOLUT.
Distribution should be reported as a function
of HDOP, the number of channels (i.e. 3,
≥4) and the number of bursts used in the
computation.
Measurement could be
done over 5, 10 or 15
minutes.
Four+ MEO Channels
Independent Location
Probability
Independent Location
Error
Average and standard deviation of independent location
errors obtained for a given number of fixed beacons after a
given period of time, with a max. HDOP of [TBD].
• Sample size: ≥ TBD
• Standard beacon transmissions
• BCN/Sat. elevation angle ≥ [5°]
• LUT/Sat. elevation angle ≥ [5°]
Results may be affected by
geo. area considered.
Can also be reported as a
function of HDOP and the
number of bursts.
Time to First Location Time elapsed between beacon activation and the first 2D
independent location by a MEOLUT with an error less than
5 km, with a max. HDOP of [TBD].
TOA Estimation Error Average
(bias)
and
standard
deviation
of
TOA
measurements performed by a MEOLUT.
TBD
Distribution of errors
should also be provided.
FOA Estimation Error Average (bias) and standard deviation of FOA measurements
performed by a MEOLUT.
TBD
Definitions:
HDOP:
TBD.
Independent location:
Location obtained by a MEOLUT, independently of any encoded position data in the beacon
message.
Valid message / Complete message:
See C/S T.002 and C/S T.009.
MEO channel:
Unique beacon-satellite-MEOLUT antenna path.
Standard beacon:
TBD (Use of “standard” beacon or controlled simulator transmissions should be
documented).
- END OF ANNEX N -
O-3
ANNEX O
[Annex O has been removed entirely]
- END OF ANNEX O -
P-1
ANNEX P
ANNEX F OF DOCUMENT C/S A.002 MODIFIED TO ACCOUNT FOR
MEOLUT TOA/FOA DATA TRANSFERT
Annex P is actually Annex F of C/S A.002 in its entirety, but modified to account for MEOLUT
TOA/FOA data transfer via FTP. Strike out and italicized text represents suggested changes that
would ultimately appear in document C/S A.002 (SID).
Note: In this Annex, existing text in the document C/S A.002 (SID) is in normal fonts, deletions
are shown as strike out fonts and additions are in italic fonts.
COSPAS-SARSAT STANDARD FOR THE TRANSMISSION OF
SIT MESSAGES VIA FTP
F.1
FILE TRANSFER PROTOCOL (FTP) COMMUNICATIONS
Each MCC Ground Segment facility (e.g., MCC or MEOLUT) communicating via FTP shall
comply with the applicable standards described in the Internet Engineering Task Group
document RFC 959 - File Transfer Protocol, which can be found at the following web address:
www.ietf.org.
F.1.1 File naming Convention
An MCC A ground segment facility shall send a SITmessage by writing a file on the FTP server
of the receiving MCCfacility. Each file shall contain exactly one SITmessage.
The FTP file name format shall be “?SRCE\_?DEST\_?CUR\#.TXT”, where:
- “?SRCE” is the Source MCC Name (www.cospas-sarsat.org), or the Source MEOLUT
Name (www.cospas-sarsat.org)
- “?DEST” is the Destination MCC Name (www.cospas-sarsat.org) or the Destination
MEOLUT Name (www.cospas-sarsat.org), and
- “?CUR#” is the Current Message Number (Message Field 1).
The FTP file name shall contain only upper case characters. For example, a file with the name
“USMCC\_CMCC\_02345.TXT” contains Current Message Number 02345 sent by the
USMCC to the CMCC.
Any MCCfacility that wants to receive data via FTP shall provide the Host Name and/or
Internet Protocol (IP) Address, User Name, Password, and Message Directory Name in
Table F.1, to enable other MCCsGround Segment facilities to place data on the FTP server of
the receiving MCCfacility. On a bilateral basis, the receiving and sending MCCfacility should
agree on passwords and other security measures. It is the responsibility of the receiving
MCCfacility to provide adequate security for its FTP server.
The sending MCCfacility shall write a file with a file name extension of “.TMP” on the FTP
server of the receiving MCCfacility. A file is given a temporary name to prevent the receiving
P-2
MCCfacility from processing a file before it is complete. Once the file transfer is complete,
the sending MCCfacility shall rename the file with an extension “.TXT”. Once the file has
been renamed, the sending MCCfacility shall not manipulate the file. The receiving
MCCfacility shall not process files with an extension of “.TMP”. The receiving MCCfacility
shall be responsible for disposing of files placed on its FTP server. (paragraph split added)
If the receiving MCC detects an anomalous condition in the FTP file transfer, it shall notify the
transmitting MCC. (paragraph split removed)If a FTP file transfer fails for any reason the
transmitting MCC shall try to resend the message, and notify the receiving MCC if the failure
persists.
If the receiving MEOLUT detects an anomalous condition in the FTP file transfer, it shall
notify its associated MCC. If a FTP file transfer fails for any reason the transmitting MEOLUT
shall maintain a [10] minute buffer of messages. Upon re-establishment of a connection the
transmitting MEOLUT shall send the buffered messages. If MEOLUT FTP file transfer failures
persist, the transmitting MEOLUT shall notify its associated MCC.
Each MCCfacility communicating via FTP shall operate in binary transfer mode.
F.2
FILE TRANSFER PROTOCOL (FTP) INFORMATION LIST
A list of information used to send messages to an MCCa facility via FTP is provided in this
section. This list is composed of 6 items:
1.
Receiving MCCGround Segment Facility
2.
Host Name
3.
IP Address
4.
User Name
5.
Password
6.
Message Directory Path
F.2.1 Receiving MCC Ground Segment Facility
The name of the MCCGround Segment Facility to receive data via FTP. For MCCs, Tthis
name matches the MCC Identification Code in the Cospas-Sarsat website www.cospas-
sarsat.org. For MEOLUTs, this name matches the MEOLUT name in , noting that spaces are
always replaced with an underscore (“\_”) character.
F.2.2 Host Name
This is the FTP Host Name of the receiving MCCGround Segment Facility. *** indicates that
the Host Name is provided on a need to know basis.
P-3
F.2.3 Internet Protocol (IP) Address
This is the Internet Protocol Address referenced to reach the receiving MCCGround Segment
Facility. *** indicates that the IP Address is provided on a need to know basis.
F.2.4 User Name
The User Name required to login to the FTP server of the receiving MCCfacility. If the value
is “Sending MCCGround Segment facility Name”, then the user name is the name of the
sending MCCGround Segment facility, per Table B.2A.1 or B.3. *** indicates that the User
Name is provided on a need to know basis.
F.2.5 Password
The password required to access the FTP server of the receiving MCCfacility. *** indicates
that the Password is provided on a need to know basis.
F.2.6 Message Directory Path
The path of the directory into which message files shall be written.
indicates that each MCCfacility will put messages in a sub-directory per MCCfacility where
the sub-directory name is the name of the sending MCCfacility, per the Cospas-Sarsat website
www.cospas-sarsat.org for MCCs and per the Cospas-Sarsat website www.cospas-sarsat.org
for MEOLUTs.
F.3
SECURITY
All MCCsGround Segment facilities with an Internet connection must be protected by firewall
technology.
F.3.1 Passwords
MCCsGround Segment facilities shall formulate passwords using security best practices. The
passwords shall have the following characteristics:
-
contain at least 8 characters
-
not have any characters that are “blank”
-
six of the characters shall occur once in the password
-
at least one of the characters must be a number (0-9) or a special character (~,!,$,\#,%,\*)
– see Table F.2
-
at least one of the characters must be from the alphabet (upper or lower case)
-
passwords shall not include:
•
words found in any dictionary (English or other language), spelled forward or
backward system User Ids
•
addresses or birthdays
•
common character sequences (e.g., 123, ghijk, 2468)
P-4
•
vendor-supplied default passwords (e.g., SYSTEM, Password, Default, USER,
Demo)
•
words that others might guess
MCCsGround Segment facilities shall change passwords at least semi-annually.
To protect passwords from unauthorized disclosure MCCsfacilities shall exchange passwords
by telephone or facsimile if allowed by security authorities at each MCCfacility. MCCs
Facilities shall coordinate the exchange of new passwords during the last full work week of
April and October of each year. MCCsFacilities exchanging passwords shall agree on an
implementation date that is not later than the end of the week during which new passwords are
exchanged.
Table F.1: FTP Password Special Characters
SYMBOL
NAME
~
TILDE
!
EXCLAMATION POINT
@
AT SYMBOL
\#
OCTOTHORPE
$
DOLLAR SIGN
%
PERCENT
^
CHAPEAU / HAT
&
AMPERSAND
\*
ASTERIX
)
CLOSE PARENTHESES
(
OPEN PARENTHESES
`
APOSTROPHE
-
HYPHEN
“
QUOTATION
/
VIRGULESLASH
F.3.2 Access
Access permissions on all directories and files on the FTP server shall follow the principle of
“least permissions” to ensure that no unauthorized access is allowed. “Least permissions”
means that each user is granted the minimum access required to perform their assigned tasks.
MCCsFacilities shall check IP addresses to limit server access only to authorized users.
MCCsFacilities shall allow access to their FTP servers only through ports 20 and 21. All other
ports that are not being used shall be closed.
F.3.3 Anonymous FTP
MCCs Facilities shall not use anonymous FTP.
P-5
F.3.4 Encryption of Critical Information
MCCsFacilities shall implement methodologies to encrypt FTP login names (userids) and
passwords during file transmission to prevent unauthorized disclosure. These methodologies
include FTP over Internet VPN. Standards for the use of hardware VPN are contained in
Annex G.
F.3.5 Monitoring for a Potential Security Breach
MCCsFacilities shall monitor the FTP servers for abnormal activity. If a breach of security is
found, MCCsGround Segment facility operators shall notify all FTP correspondents as soon as
possible to minimize exposure.
Examples of items that should be monitored on a FTP server include:
Event logs
Should be set and checked for failed login attempts
Gaps in time and date stamps
Attempts to elevate privileges
Disk Space
Unexplained loss of disk space
Unexplained disk access
Unexplained events
Large number of failures (system or programs crash)
Unexplained process or programs running
New users added
Virus protection has been disabled
F.3.6 Security Patches
MCCsFacilities shall apply the latest software and security patches to their FTP servers as soon
as possible.
- END OF ANNEX P -
R-1
ANNEX R
PRELIMINARY SAR/BDS TRANSPONDER CHARACTERISTICS
Parameter
Interoperability
Requirement
Design result of
MEOSAR
Unit
Uplink frequency range (a)
406.0~406.1
406.0~406.1
MHz
Receive centre frequency
Normal mode
406.050
406.050
MHz
Narrowband mode
406.043
406.043
Nominal input power at antenna
dBw
Maximum input power at antenna
dBw
System dynamic range
dB
Receive antenna polarisation
/
RHCP
Receive antenna gain at EoC (a)
/
11.5
dBi
Receive antenna axial ratio
＜ 2.5
＜ 2
dB
Satellite G/T
-17.7
＞ -15.3
dB/K
System noise temperature (b)
/
K
Bandpass characteristics
Normal mode
1dB＞80kHz
1dB＞80kHz
3dB＞90kHz
3dB＞90kHz
10dB＜110kHz
10dB＜110kHz
45dB＜170kHz
45dB＜170kHz
70dB＜200kHz
70dB＜200kHz
Narrowband mode
1dB＞50kHz
1dB＞50kHz
10dB＜75kHz
10dB＜75kHz
45dB＜130kHz
45dB＜130kHz
70dB＜160kHz
70dB＜160kHz
Group delay uncertainty（95% conf.）
＜ 500
ns
Group delay over 4kHz
(slope) (c)
Normal mode
≤ 10
≤ 9
μs/4kHz
Narrowband mode
≤ 9
Transponder gain modes
/
ALC
ALC time constant
＜ 80 ms
＜ 60 ms
ALC dynamic range
＞ 30
Transponder gain
＞ 180
＞ 180
dB
Transponder linearity
＞ 30
30.5
dBc
Frequency translation accuracy
± 2x10-11
± 2x10-11
Frequency translation
Short term stability (100ms)
≤ 1x10-11
≤ 1x10-11
R-2
Parameter
Interoperability
Requirement
Design result of
MEOSAR
Unit
Translation frequency stability
/
RAFS：＜ 3x10-12/1s
＜ 1x10-12/10s
＜ 3x10-13/100s
Downlink frequency band
/
1544.16~1544.26
MHz
Downlink centre
frequency
Normal mode
/
1544.210
MHz
Narrowband mode
/
1544.203
MHz
Downlink antenna polarisation
/
[RHCP]
Transmit antenna axial ratio
/
＜1.5
dB
Downlink EIRP
＞18.0
dBw
EIRP stability in ALC mode
/
1.0
dBpk-pk
- END OF ANNEX R -
- END OF DOCUMENT -
Cospas-Sarsat Secretariat
1250 Boul. René-Lévesque 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