Cospas-Sarsat specification summaries moved to reference/ for internal use only. Links updated to point to official cospas-sarsat.int site. The extracted images remain in public/ for use in other pages.
2018 lines
81 KiB
Markdown
2018 lines
81 KiB
Markdown
---
|
||
title: "T002: C/S T.002 - Issue 5 - Rev. 1"
|
||
description: "Official Cospas-Sarsat T-series document T002"
|
||
sidebar:
|
||
badge:
|
||
text: "T"
|
||
variant: "note"
|
||
# Extended Cospas-Sarsat metadata
|
||
documentId: "T002"
|
||
series: "T"
|
||
seriesName: "Technical"
|
||
documentType: "specification"
|
||
isLatest: true
|
||
issue: 5
|
||
revision: 1
|
||
documentDate: "March 2022"
|
||
originalTitle: "C/S T.002 - Issue 5 - Rev. 1"
|
||
---
|
||
|
||
> **📋 Document Information**
|
||
>
|
||
> **Series:** T-Series (Technical)
|
||
> **Version:** Issue 5 - Revision 1
|
||
> **Date:** March 2022
|
||
> **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents)
|
||
|
||
---
|
||
|
||
COSPAS-SARSAT
|
||
LEOLUT
|
||
PERFORMANCE SPECIFICATION
|
||
AND DESIGN GUIDELINES
|
||
C/S T.002
|
||
Issue 5 – Revision 1
|
||
|
||

|
||
|
||
|
||
COSPAS-SARSAT LEOLUT
|
||
PERFORMANCE SPECIFICATION AND DESIGN GUIDELINES
|
||
History
|
||
Issue
|
||
Revision
|
||
Date
|
||
Comments
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-2)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-7)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-21)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-23)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-29)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-33)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-35)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-37)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-41)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-43)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-47)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-49)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-59)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-66)
|
||
|
||
|
||
TABLE OF CONTENTS
|
||
Page
|
||
History ................................................................................................................................................. i
|
||
Table of Contents ................................................................................................................................. ii
|
||
List of Figures
|
||
................................................................................................................................. v
|
||
List of Tables
|
||
................................................................................................................................. v
|
||
1.
|
||
INTRODUCTION................................................................................................. 1-1
|
||
1.1
|
||
Overview ............................................................................................................. 1-1
|
||
1.2
|
||
Scope .................................................................................................................... 1-1
|
||
1.3
|
||
Document Organisation ..................................................................................... 1-1
|
||
1.4
|
||
Reference Documents ......................................................................................... 1-1
|
||
2.
|
||
COSPAS-SARSAT LEOLUT DESCRIPTION ................................................. 2-1
|
||
3.
|
||
OPERATIONAL REQUIREMENTS ................................................................. 3-1
|
||
3.1
|
||
LEOLUT Data Availability ............................................................................... 3-1
|
||
3.2
|
||
Data Requirements ............................................................................................. 3-1
|
||
3.3
|
||
Data Channels ..................................................................................................... 3-1
|
||
3.4
|
||
Satellite Tracking Capability ............................................................................ 3-1
|
||
3.5
|
||
Satellite Visibility ................................................................................................ 3-2
|
||
3.6
|
||
Status and Alarm ................................................................................................ 3-2
|
||
3.7
|
||
RF Radiation and Emissions ............................................................................. 3-2
|
||
3.8
|
||
Data Archiving .................................................................................................... 3-2
|
||
4.
|
||
FUNCTIONAL AND PROCESSING REQUIREMENTS ............................... 4-1
|
||
4.1
|
||
Functional Requirements .................................................................................. 4-1
|
||
4.1.1
|
||
Antenna and RF Subsystem ..................................................................... 4-1
|
||
4.1.2
|
||
Time and Frequency Reference Subsystem ............................................. 4-1
|
||
4.1.3
|
||
Orbit Maintenance Subsystem ................................................................. 4-1
|
||
4.1.4
|
||
MCC Interface .......................................................................................... 4-2
|
||
4.2
|
||
406 MHz Channels Processing .......................................................................... 4-2
|
||
4.2.1
|
||
General Processing Requirements ............................................................ 4-2
|
||
4.2.2
|
||
Beacon Message Recovery....................................................................... 4-2
|
||
4.2.3
|
||
Bit Verification ......................................................................................... 4-3
|
||
4.2.4
|
||
Beacon Message Validation ..................................................................... 4-4
|
||
4.2.5
|
||
Beacon Message Processing..................................................................... 4-5
|
||
4.2.6
|
||
LEOLUT Time and Frequency Requirements ......................................... 4-8
|
||
4.2.7
|
||
Doppler Processing and Validation .......................................................... 4-9
|
||
|
||
|
||
4.2.8
|
||
Transmission of Alert Data to MCC ...................................................... 4-12
|
||
5.
|
||
PERFORMANCE REQUIREMENTS ............................................................... 5-1
|
||
5.1
|
||
General ................................................................................................................ 5-1
|
||
5.1.1
|
||
RF Signal Margin ..................................................................................... 5-1
|
||
5.1.2
|
||
Processing Time ....................................................................................... 5-1
|
||
5.1.3
|
||
Orbit Determination ................................................................................. 5-1
|
||
5.1.4
|
||
Ambiguity Resolution .............................................................................. 5-2
|
||
5.1.5
|
||
Error Ellipse ............................................................................................. 5-2
|
||
5.2
|
||
SARP Channel .................................................................................................... 5-2
|
||
5.2.1
|
||
Data Recovery .......................................................................................... 5-2
|
||
5.2.2
|
||
Time and Frequency Calculation ............................................................. 5-2
|
||
5.2.3
|
||
Beacon Capacity ....................................................................................... 5-2
|
||
5.2.4
|
||
Location Accuracy ................................................................................... 5-2
|
||
5.2.5
|
||
Ambiguity Resolution .............................................................................. 5-3
|
||
5.3
|
||
SARR Channel (G-SARP Processing) .............................................................. 5-3
|
||
5.3.1
|
||
Signal Sensitivity...................................................................................... 5-3
|
||
5.3.2
|
||
Beacon Message Throughput ................................................................... 5-3
|
||
5.3.3
|
||
Probability of Doppler Location .............................................................. 5-3
|
||
5.3.4
|
||
Time and Frequency Calculation ............................................................. 5-3
|
||
5.3.5
|
||
Beacon Capacity ....................................................................................... 5-4
|
||
5.3.6
|
||
Location Accuracy ................................................................................... 5-4
|
||
5.3.7
|
||
Ambiguity Resolution .............................................................................. 5-4
|
||
5.3.8
|
||
Prevention of False Alerts Caused by Processing Anomalies.................. 5-4
|
||
5.3.9
|
||
Processing Bandwidth .............................................................................. 5-4
|
||
5.4
|
||
Combined SARP and SARR Channel Processing ........................................... 5-4
|
||
5.5
|
||
Combined LEO/GEO Processing ..................................................................... 5-5
|
||
5.5.1
|
||
Nominal and Marginal Solutions ............................................................. 5-5
|
||
5.5.2
|
||
Location Accuracy for Minimum Point Solutions ................................... 5-5
|
||
ANNEX A : DESIGN GUIDELINES FOR DETERMINING THE DOWNLINK
|
||
POWER BUDGET FOR THE 406 MHz SARP CHANNEL ........................ A-1
|
||
A.1 Introduction ....................................................................................................... A-1
|
||
A.2 Explanation of the downlink budget................................................................ A-1
|
||
A.3 Calculations ........................................................................................................ A-2
|
||
A.4 Summary ............................................................................................................ A-3
|
||
ANNEX B : BEACON MESSAGE PROCESSING .............................................................. B-1
|
||
|
||
|
||
ANNEX C : OPTIONAL PROCESSING OF INTERFERENCE USING THE 406
|
||
MHZ REPEATER BAND ................................................................................ C-1
|
||
C.1 Introduction ....................................................................................................... C-1
|
||
C.2 Functional Description ...................................................................................... C-1
|
||
C.3 Operational Recommendations ........................................................................ C-1
|
||
C.4 Performance Specification ................................................................................ C-1
|
||
C.4.1 Processing Time ...................................................................................... C-1
|
||
C.4.2 Location Accuracy .................................................................................. C-1
|
||
LIST OF FIGURES
|
||
Figure 2-1:
|
||
A Typical Cospas-Sarsat LEOLUT Functional Block Diagram .......................... 2-2
|
||
Figure B. 1:
|
||
Beacon Message Processing (Long Message format) ......................................... B-1
|
||
Figure B. 2:
|
||
Beacon Message Processing (Short Message format) ......................................... B-2
|
||
Figure B. 3:
|
||
Examples of Encoded Data Selection for Multiple Message Beacon Events - Long
|
||
Message Format .................................................................................................. B-3
|
||
Figure B. 4:
|
||
Examples of Encoded Data Selection for Multiple Message Beacon Events - Long
|
||
Message Format - (continued) ............................................................................. B-4
|
||
Figure B. 5:
|
||
Examples of Encoded Data Selection for Multiple Message .............................. B-5
|
||
|
||
|
||
LIST OF TABLES
|
||
Table 4.1:
|
||
406 MHz Beacon Message Processing ................................................................ 4-7
|
||
Table A.1:
|
||
Downlink Power Budget Parameters for the Cospas and Sarsat Processed Data
|
||
Stream (PDS) Channels ....................................................................................... A-4
|
||
|
||
1-1
|
||
|
||
1.
|
||
INTRODUCTION
|
||
The purpose of the Cospas-Sarsat System is to provide distress alert and location data for search
|
||
and rescue (SAR), using spacecraft and ground facilities to detect and locate the signals of Cospas-
|
||
Sarsat distress radiobeacons operating on 406 MHz. An earth receiving station that tracks low
|
||
earth orbiting (LEO) satellites in the Cospas-Sarsat System (the Cospas-Sarsat LEOSAR system)
|
||
is called a LEOSAR Local User Terminal (LEOLUT). The LEOLUT transmits alert and location
|
||
data to the associated Cospas-Sarsat Mission Control Centre (MCC) for subsequent distribution to
|
||
SAR authorities.
|
||
For acceptance as part of the Cospas-Sarsat System, a LEOLUT shall be commissioned as defined
|
||
in the document C/S T.005, Cospas-Sarsat LEOLUT Commissioning Standard, to verify
|
||
compliance of its performance with this specification.
|
||
This specification describes the minimal operational capabilities and performance requirements of
|
||
a Cospas-Sarsat LEOLUT. The specifications in this document apply to data transmitted by a
|
||
LEOLUT for distribution in the Cospas-Sarsat MCC network.
|
||
A brief description of a LEOLUT is provided in section 2. Operational requirements are provided
|
||
in section 3, section 4 defines the functional and processing requirements, and section 5 contains
|
||
specific performance requirements for a LEOLUT.
|
||
The Annexes to this document contain:
|
||
reference information for LEOLUT operators and designers in Annexes A and B;
|
||
specific processing requirements in Annex B; and
|
||
optional processing guidelines in Annex C.
|
||
The following documents contain useful information pertaining to LEOLUT specifications,
|
||
signals processed by LEOLUTs, and the procedures for LEOLUT integration into the Cospas-
|
||
Sarsat System:
|
||
C/S T.001
|
||
Specification for Cospas-Sarsat 406 MHz Distress Beacons;
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
1-2
|
||
|
||
C/S T.003
|
||
Description of the Cospas-Sarsat LEOSAR Space Segment;
|
||
C/S T.006
|
||
Cospas-Sarsat Orbitography Network Specification;
|
||
C/S T.005
|
||
Cospas-Sarsat LEOLUT Commissioning Standard;
|
||
C/S T.009
|
||
Cospas-Sarsat GEOLUT Performance Specification and Design
|
||
Guidelines;
|
||
C/S T.010
|
||
Cospas-Sarsat GEOLUT Commissioning Standard;
|
||
C/S A.001
|
||
Cospas-Sarsat Data Distribution Plan (DDP);
|
||
C/S A.002
|
||
Cospas-Sarsat Mission Control Centres Standard Interface
|
||
Description (SID);
|
||
C/S A.003
|
||
Cospas-Sarsat System Monitoring and Reporting; and
|
||
C/S A.005
|
||
Cospas-Sarsat Mission Control Centre Performance Specification
|
||
and Design Guidelines.
|
||
- END OF SECTION 1 -
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
2-1
|
||
|
||
2.
|
||
COSPAS-SARSAT LEOLUT DESCRIPTION
|
||
A LEOLUT is a ground receiving station in the Cospas-Sarsat LEOSAR system that detects,
|
||
characterises and locates emergency beacons, and forwards the appropriate information to an
|
||
MCC. It may process one or more channels that are modulated upon the 1544.5 MHz LEOSAR
|
||
downlink carrier. Additionally, it may use information provided by the GEOSAR system in the
|
||
processing of distress alerts.
|
||
The LEOLUT is defined in this document as a function. It may be implemented in many ways,
|
||
such as sharing equipment or software with an MCC.
|
||
A LEOLUT consists of at least the following basic components and appropriate interfaces:
|
||
an antenna and radio frequency subsystem,
|
||
a processor,
|
||
a time and/or frequency reference subsystem,
|
||
an orbit maintenance subsystem, and
|
||
an MCC interface.
|
||
A typical Cospas-Sarsat LEOLUT functional block diagram is shown in Figure 2.1.
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
2-2
|
||
|
||
Figure 2-1:
|
||
A Typical Cospas-Sarsat LEOLUT Functional Block Diagram
|
||
The Search And Rescue Processor (SARP) instrument receives signals from Cospas-Sarsat
|
||
beacons, measures the time of reception and frequency of the signal, and transmits this information
|
||
along with beacon message data on the Processed Data Stream (PDS) channel of the 1544.5 MHz
|
||
downlink. The SARP can store and rebroadcast distress beacon information thereby providing
|
||
global as well as local-mode coverage. The SARP instrument is available on Cospas and Sarsat
|
||
satellites.
|
||
Beacon signals received via the Search And Rescue Repeater (SARR) instrument on Sarsat
|
||
satellites do not contain embedded time and frequency information. Therefore, the LEOLUT has
|
||
to determine these parameters for the 406 MHz SARR channel. The LEOLUT equipment that
|
||
processes beacon data from the 406 MHz SARR channel is referred to as a Ground-Search and
|
||
Rescue Processor (G-SARP).
|
||
A LEOLUT may use information provided by the Geostationary Search and Rescue (GEOSAR)
|
||
system for combined LEO/GEO processing as described in section 4. The GEOSAR information
|
||
used for this purpose must be provided by GEOLUTs which have been commissioned in
|
||
accordance with document C/S T.010 (GEOLUT commissioning).
|
||
Antenna
|
||
Receiver
|
||
Phase
|
||
Demodulator
|
||
Antenna
|
||
Drive
|
||
A/D
|
||
406 MHz
|
||
GSARP
|
||
Processor
|
||
Comm.
|
||
Interface
|
||
Bit & Frame
|
||
Sync.
|
||
406 MHz
|
||
Data
|
||
Processor
|
||
Control
|
||
Electronics
|
||
Time Code
|
||
Generator
|
||
Frequency
|
||
Standard
|
||
Combined
|
||
LEO/GEO
|
||
Processing
|
||
Updated Orbit Time
|
||
Orbital Data
|
||
406 MHz
|
||
SARR Band
|
||
406 MHz Pre-
|
||
Processor Data
|
||
at 2400 BPS
|
||
GEOLUT
|
||
Data
|
||
Orbital Data
|
||
From MCC
|
||
ELT/EPIRB
|
||
Locations To
|
||
MCC
|
||
Satellite
|
||
Downlink
|
||
1544.5 MHz
|
||
Antenna
|
||
Antenna
|
||
Receiver
|
||
Receiver
|
||
Phase
|
||
Demodulator
|
||
Antenna
|
||
Drive
|
||
A/D
|
||
406 MHz
|
||
GSARP
|
||
Processor
|
||
Comm.
|
||
Interface
|
||
Bit & Frame
|
||
Sync.
|
||
406 MHz
|
||
Data
|
||
Processor
|
||
Control
|
||
Electronics
|
||
Time Code
|
||
Generator
|
||
Frequency
|
||
Standard
|
||
Combined
|
||
LEO/GEO
|
||
Processing
|
||
Updated Orbit Time
|
||
Orbital Data
|
||
406 MHz
|
||
SARR Band
|
||
406 MHz Pre-
|
||
Processor Data
|
||
at 2400 BPS
|
||
GEOLUT
|
||
Data
|
||
Orbital Data
|
||
From MCC
|
||
ELT/EPIRB
|
||
Locations To
|
||
MCC
|
||
Satellite
|
||
Downlink
|
||
1544.5 MHz
|
||
|
||
2-3
|
||
|
||
A Cospas-Sarsat LEOLUT shall include the SARP channel which processes the PDS of the
|
||
satellite SARP.
|
||
In addition, Cospas-Sarsat LEOLUTs can also include:
|
||
a SARR channel to process the 406 MHz signals relayed by the satellite Search and
|
||
Rescue Repeater; and
|
||
-
|
||
optional processing of the 406 MHz channels which can use data provided by the
|
||
406 MHz GEOSAR system to assist with the processing of distress alerts.
|
||
Cospas-Sarsat LEOLUTs may also process the SARR channel to characterize and locate
|
||
interferers.
|
||
The operational, functional and performance requirements for these processing channels are
|
||
described in the following sections of this document. They are intended to ensure that:
|
||
the LEOLUT is available and capable of receiving and processing:
|
||
i. local and global-mode 406 MHz SARP data;
|
||
ii. beacon signals in the 406 MHz SARR channel; and
|
||
iii. 406 MHz beacon data from a GEOLUT, if combined LEO/GEO
|
||
processing is implemented; and
|
||
the LEOLUT provides timely reliable alerts and accurate position data by:
|
||
i. detecting valid and invalid 406 MHz beacon messages and processing
|
||
them in accordance with this specification;
|
||
ii. verifying whenever possible that the beacon identification and encoded
|
||
position information are valid;
|
||
iii. properly selecting the data points used to calculate Doppler positions;
|
||
iv. providing updated position information to the MCC, as appropriate;
|
||
v. validating calculated Doppler positions; and
|
||
vi. maintaining an accurate time reference.
|
||
- END OF SECTION 2 -
|
||
|
||

|
||
|
||

|
||
|
||
3-1
|
||
|
||
3.
|
||
OPERATIONAL REQUIREMENTS
|
||
The basic operational objective of a LEOLUT is to process data from as many satellite passes as
|
||
possible and to send the resultant alert data to its associated MCC, according to the specifications
|
||
contained in this document. Once a LEOLUT has been commissioned and connected to the
|
||
Cospas-Sarsat network through an MCC, it shall continue to meet the specifications of this
|
||
document
|
||
A LEOLUT commissioned for operation within the Cospas-Sarsat System, shall provide data to
|
||
the associated MCC twenty-four (24) hours a day, seven (7) days a week with less than five percent
|
||
(5%) downtime calculated over a year
|
||
The LEOLUT shall provide all data necessary for the MCC to distribute relevant alert data to the
|
||
appropriate destination(s), according to the document C/S A.002 (SID), Cospas-Sarsat MCC
|
||
Standard Interface Description.
|
||
LEOLUTs must suffer no degradation in performance nor produce erroneous outputs to the MCC
|
||
due to the reception of data from ELT(DT)s.
|
||
A LEOLUT shall process signals from Cospas-Sarsat radiobeacons in the SARP channel (i.e., the
|
||
2.4 kilobit per second Processed Data Stream (PDS)). The SARP processing shall include both
|
||
local-mode and global-mode data. Optionally, the LEOLUT may process signals from beacons in
|
||
the SARR channel. Furthermore, the LEOLUT may optionally use 406 MHz beacon data provided
|
||
by commissioned GEOLUTs for combined LEO/GEO processing. The LEOLUT shall meet all
|
||
the operational, functional, processing, and performance requirements contained in this document
|
||
for any optional channels it processes.
|
||
The LEOLUT shall be capable of tracking all non-conflicting Cospas-Sarsat satellite passes,
|
||
subject to the processing time requirements.
|
||
The LEOLUT shall be capable of implementing pass scheduling algorithms that take into account
|
||
the time since the LUT last tracked each satellite as well as immediate operational considerations,
|
||
so that the LUT tracks each operational satellite every 12 hours at a minimum.
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
3-2
|
||
|
||
The LEOLUT should be located to give the widest possible horizon because it is desirable to be
|
||
able to track satellites down to the horizontal plane for all azimuth angles. The LEOLUT shall be
|
||
capable of continuously receiving and processing all satellite data for all portions of a satellite pass
|
||
above a 5-degree elevation angle* without any data degradation or loss.
|
||
The LEOLUT shall provide the MCC with information to allow the MCC to determine any
|
||
degradation of its operational capability.
|
||
The LEOLUT shall not radiate or emit any radio frequency (RF) signals that will interfere with
|
||
the functioning of the Cospas-Sarsat System.
|
||
For each satellite pass tracked, the LEOLUT shall maintain access to the data elements listed below
|
||
for a period of at least three months:
|
||
the 30 hexadecimal character representation of each beacon message;
|
||
the frequency and time measurement of each beacon burst provided by the SARR
|
||
and SARP channels;
|
||
the beacon power measurement for each beacon burst provided by the SARP
|
||
channel;
|
||
the C/No ratio for each beacon burst provided by the SARR channel;
|
||
the beacon locations and related solution data calculated by the LEOLUT;
|
||
the satellite orbit vectors and time calibration (TCAL) settings used in the
|
||
processing of the above data;
|
||
the solution data for of all 406 MHz interferers detected; and
|
||
the log files that capture the status of the LEOLUT during the time period that the
|
||
LEOLUT tracked the satellite.
|
||
- END OF SECTION 3 -
|
||
* except where prevented by local obstructions
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
4-1
|
||
|
||
4.
|
||
FUNCTIONAL AND PROCESSING REQUIREMENTS
|
||
The basic functional and processing requirements which apply to the channels implemented in a
|
||
Cospas-Sarsat LEOLUT, are to:
|
||
maintain and update satellite ephemeris, acquire, track and receive the downlink
|
||
signal from Cospas-Sarsat satellites;
|
||
maintain and update the SARP time and frequency parameters;
|
||
maintain and update the required System time and frequency references;
|
||
demodulate the SARP and SARR channels (i.e., 406 MHz PDS and 406 MHz
|
||
repeated);
|
||
process SARP and SARR channels as described in section 4.2;
|
||
calculate Doppler positions whenever enough reliable data is available; and
|
||
provide the resultant data to the associated MCC in accordance with the
|
||
requirements of the document C/S A.002, Cospas-Sarsat MCCs Standard Interface
|
||
Description.
|
||
4.1.1
|
||
Antenna and RF Subsystem
|
||
Throughout the complete pass, the antenna and RF subsystem shall be able to acquire, track and
|
||
receive the downlink signal from Cospas-Sarsat satellites.
|
||
4.1.2
|
||
Time and Frequency Reference Subsystem
|
||
The LEOLUT shall be capable of maintaining system time with sufficient accuracy to ensure that
|
||
the overall location accuracy is met. It is recommended that the LEOLUT system time be
|
||
maintained to within ten (10) milliseconds of universal coordinated time (UTC). Additionally, it
|
||
is recommended that the frequency reference for all applicable local oscillators should have a
|
||
stability of five parts in ten raised to the power of nine, over fifteen minutes.
|
||
4.1.3
|
||
Orbit Maintenance Subsystem
|
||
The LEOLUT shall be able to maintain accurate satellite orbital elements and tracking schedules
|
||
for up to eight satellites.
|
||
Orbit determination is initialised by data obtained from the Cospas-Sarsat MCC network.
|
||
Thereafter, in the normal state, the LEOLUT shall be capable of maintaining the satellite orbital
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
4-2
|
||
|
||
elements continually, independently of the Cospas-Sarsat MCC network. The LEOLUT shall also
|
||
be able to receive and use the orbital elements from the associated MCC.
|
||
The LEOLUT shall be capable of routinely performing orbital updates using at least three
|
||
orbitography/reference beacons, including at least one in each hemisphere, so that the LEOLUT
|
||
has sufficient beacon message data with adequate geographic diversity to compute accurate orbit
|
||
vectors when current orbit vectors are not available from the Cospas-Sarsat MCC network.
|
||
In the event of a scheduled satellite manoeuvre (as described in document C/S A.001), the
|
||
LEOLUT may not be able to maintain accurate orbital elements. Therefore, the LEOLUT shall
|
||
use the orbital elements from the associated MCC to initialise the LEOLUT orbital elements
|
||
without regard to the previous orbital elements at the LEOLUT.
|
||
The LEOLUT shall be capable of maintaining the satellite orbital elements using at least two of
|
||
the methods described in Annex III/D of the document C/S A.001 (DDP).
|
||
4.1.4
|
||
MCC Interface
|
||
The LEOLUT must provide timely information of the level of quality and detail specified in the
|
||
documents C/S A.002 (SID), and C/S A.005 (MCC specification).
|
||
4.2.1
|
||
General Processing Requirements
|
||
The LEOLUT shall process beacon messages as described in this section. The LEOLUT shall
|
||
process all available information and provide, as appropriate, Doppler locations, encoded position
|
||
data or unlocated alerts for individual beacon events. The processing consists of the following
|
||
sequence: message recovery, bit verification, message validation, message processing, Doppler
|
||
location processing and transmission of resultant alert data to the associated MCC. Unless
|
||
specifically stated otherwise, all processing requirements apply to both the SARP and SARR
|
||
channels as well as combined LEO/GEO processing.
|
||
4.2.2
|
||
Beacon Message Recovery
|
||
4.2.2.1 SARP Channel Data Recovery
|
||
The LEOLUT must synchronise to the SARP channel, decode and sort messages for individual
|
||
beacon events and calculate Doppler locations. The LEOLUT shall be capable of acquiring both
|
||
local-mode and global-mode PDS data for processing. The LEOLUT shall process all PDS data
|
||
for any beacon event where at least one beacon burst occurred after the latest burst in the last
|
||
complete global dump acquired by the LEOLUT. Local-mode and global-mode PDS data for the
|
||
same beacon event, received during the same satellite pass, shall be combined before processing.
|
||
|
||

|
||
|
||

|
||
|
||
4-3
|
||
|
||
The local-mode and global-mode data derived from a unique beacon burst shall be processed as a
|
||
single beacon message and a single data point.
|
||
4.2.2.2 406 MHz SARR Channel Data Recovery
|
||
The LEOLUT shall only process and transmit to the associated MCC beacon messages in the
|
||
SARR channel that achieve a perfect match of bits 16 to 24 with the 9-bit frame synchronisation
|
||
pattern described in the document C/S T.001 (beacon specification).
|
||
The LEOLUT may also record for off-line processing “self-test” mode beacon messages that have
|
||
an inverted frame synchronisation pattern. However, such data shall not be used in the processing
|
||
of operational alerts.
|
||
4.2.3
|
||
Bit Verification
|
||
The LEOLUT shall detect and correct as follows, bit errors in the 406 MHz beacon messages
|
||
received through the 406 MHz SARP or SARR channels.
|
||
The digital message transmitted by 406 MHz beacons includes a 21-bit BCH error correcting code,
|
||
and, in the long message format, an additional 12-bit BCH error correcting code (except for the
|
||
long version orbitography protocol as noted below). The LEOLUT shall use these BCH codes to
|
||
verify and correct as necessary the received data. All beacon messages include the following
|
||
fields:
|
||
first protected data field (PDF-1, bits 25 to 85) which contains the beacon
|
||
identification and can include position data; and
|
||
first BCH error correcting field (BCH-1, bits 86 to 106) which contains the 21 bit
|
||
BCH error correcting code that protects the 82 bits of PDF-1 and BCH-1. The
|
||
82 bits of PDF-1 and BCH-1 are also referred to as the first protected field.
|
||
The long message format also includes:
|
||
the second protected data field (PDF-2, bits 107 to 132) which contains position
|
||
and supplementary data; and
|
||
the second BCH error correcting field (BCH-2, bits 133 to 144) which contains the
|
||
12-bit BCH error correcting code that protects the 38 bits of PDF 2 and BCH 2.
|
||
The 38 bits of PDF-2 and BCH-2 are also referred to as the second protected field.
|
||
The LEOLUT shall use BCH-1 to correct all messages that have a maximum of three bit errors in
|
||
the first protected field, and detect the existence of more than three (3) errors with a probability of
|
||
95%. The LEOLUT shall use BCH-2 to correct any messages that have one bit error in the second
|
||
protected field of the long message format and to detect the existence of two or more bit errors.
|
||
When the LEOLUT determines there are 2 or more bit errors in the second protected field, bits
|
||
|
||
4-4
|
||
|
||
113 to 144 shall all be replaced with “1”. The LEOLUT shall set bits 113 to 144 all to “0” for
|
||
short format beacon messages.
|
||
The long version of the orbitography protocol (bits 37-39 = "000") messages are processed
|
||
differently from other protocol messages in respect to verification of bits 107 to 144 and are not
|
||
subject to message validation defined in 4.2.4. While the short message portion (bits 25 106) is
|
||
error corrected by BCH-1, there is no error correction and detection applicable to bits 107 to 144.
|
||
The LEOLUT shall send the un-corrected data in bits 107 to 144 to the associated MCC.
|
||
As defined in document C/S T.001, Specification for Cospas-Sarsat 406 MHz Distress Beacons,
|
||
Standard location protocol beacon messages contain fixed values of (1101) in bits 107-110 and
|
||
National location protocol beacon messages contain fixed values of (110) in bits 107-110\*. The
|
||
other beacon protocol messages do not contain any fixed data in bits 107-110 . These fixed bits,
|
||
which immediately follow BCH-1, are used to identify a beacon message that is corrupted due to
|
||
bit-shift errors, in case the bit-shifted beacon message passes BCH-1 error detection. After using
|
||
the BCH-1 and BCH-2 to correct bit errors in the 406 MHz beacon message (as defined above),
|
||
the LEOLUT shall verify the fixed bits that begin in bit 107 for location protocol beacons (i.e.,
|
||
bits 107-110 for Standard location protocol beacons and bits 107-109 for National location
|
||
protocol beacons).
|
||
4.2.4
|
||
Beacon Message Validation
|
||
A 406 MHz beacon message is valid when:
|
||
the first protected field (PDF-1 + BCH-1) has 2 or less corrected bit errors and the
|
||
fixed bits that start in bit 107 contain no errors; or
|
||
the first protected field (PDF-1 + BCH-1) has 3 corrected bit errors and is confirmed
|
||
by an identical match with another valid message from the same beacon event and
|
||
the fixed bits that start in bits 107 contain no errors
|
||
A complete message consists of:
|
||
the first protected field (PDF-1+BCH-1) of a valid short message; or
|
||
the first and second protected fields (PDF-1+BCH-1+PDF-2+BCH-2) of a valid
|
||
long message where the second protected field contains less than 2 corrected bit
|
||
errors.
|
||
Bits 113 to 144 of the second protected field of a valid long message shall all be set to “1” if this
|
||
field contains 2 or more bit errors.
|
||
* Note that beacon cancellation protocol message has fixed bits in this range as well however these bits shall not be
|
||
used in the context of the identification of a beacon message that is corrupted due to bit-shift errors
|
||
|
||
4-5
|
||
|
||
4.2.5
|
||
Beacon Message Processing
|
||
The information content of beacon messages using location protocols may change during a satellite
|
||
pass, due to the periodic updating of encoded position data. In view of this, when sorting data, the
|
||
LEOLUT shall allow for changes from burst to burst in the content of the protected fields of
|
||
location protocol messages. Message protocols are defined in the document C/S T.001,
|
||
Specification for Cospas-Sarsat 406 MHz Distress Beacons. Only fixed bits in a message protocol
|
||
can be used for linking data points from the same beacon event and for linking GEOSAR data to
|
||
a beacon event. Therefore, after appropriate error correction, the type of protocol used shall be
|
||
determined and the received beacon message linked to other messages from the same beacon event
|
||
using the following fixed data bits:
|
||
Protocol
|
||
Fixed Data Bits Used to Identify the same Beacon Event
|
||
User & User Location
|
||
25 to 85 (61 bits)
|
||
Standard Location
|
||
25 to 64 (40 bits)
|
||
National Location
|
||
25 to 58 (34 bits)
|
||
RLS Location
|
||
25 to 66 (42 bits)
|
||
ELT(DT) Location
|
||
25 to 66 (42 bits)
|
||
Not defined
|
||
25 to 85 (61 bits)
|
||
If the beacon message fails validation (as described in section 4.2.4), the protocol is not defined;
|
||
processing for multiple invalid beacon messages is described in section 4.2.5.3.
|
||
Beacon message processing depends on the number of messages received for the same beacon
|
||
event, the number of bit errors contained in these messages, and the sequence of messages
|
||
containing variable data. Table 4.1 summarises the relationship between the number of bit errors,
|
||
the number of messages and the type of processing required. GEOSAR data used for combined
|
||
LEO/GEO processing shall not be used for beacon message processing as described below and
|
||
summarised in Table 4.1. Further details are provided below and at Annex B which describes the
|
||
processing algorithm.
|
||
4.2.5.1 Single Valid Beacon Message Processing
|
||
The LEOLUT shall suppress a single message with 3 or more bit errors in the first protected field
|
||
or any errors in the fixed bits that start in bit 107.
|
||
The LEOLUT shall process and transmit to the MCC a single valid message. However, in the case
|
||
of a single complete message using the long message format, the LEOLUT shall set bits 113 to
|
||
144 all to “1”. Bits 113 to 144 shall also all be set to “1” if the second protected field has 2 or
|
||
more errors (incomplete message) as specified in section 4.2.4.
|
||
4.2.5.2 Multiple Valid Beacon Message Processing
|
||
The information content of 406 MHz beacon messages using location protocols may change during
|
||
a satellite pass, due to the periodic updating of encoded position data. In order to ensure that only
|
||
|
||
4-6
|
||
|
||
reliable position data are forwarded to SAR services, the following principles shall apply to the
|
||
selection of the 406 MHz beacon message to be sent to the MCC when multiple beacon messages
|
||
have been received for the same beacon event.
|
||
The LEOLUT shall include in the alert transmitted to the MCC the most recent
|
||
complete beacon message that matches with another complete message from the
|
||
same beacon event.
|
||
If no complete message can be confirmed by this matching process, the LEOLUT
|
||
shall include in the alert transmitted to the MCC the most recent valid message
|
||
where the first protected data field (PDF-1) matches the first protected data field
|
||
of another beacon message. However, in the case of a valid long message or
|
||
complete long message format, the LEOLUT shall set bits 113 to 144 all to “1”.
|
||
If neither (a) or (b) above are satisfied, the LEOLUT shall include in the alert
|
||
transmitted to the MCC the most recent valid message, with bits 113 to 144 all set
|
||
to “1” in the case of a long message format.
|
||
If the LEOLUT combines SARP and SARR data from the same beacon event received
|
||
during the same satellite pass for the purpose of computing a single Doppler location, the
|
||
selection process described above shall apply to all messages received for that beacon event.
|
||
When the same beacon transmission results in one message received from the SARP channel
|
||
and one message received from the SARR channel, these two messages should not be
|
||
considered as independent for the confirmation process described above and, therefore, shall
|
||
not be used to confirm each other.
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
4-7
|
||
|
||
Table 4.1:
|
||
406 MHz Beacon Message Processing
|
||
Number of Bit Errors**
|
||
Number of Messages for same Beacon Event
|
||
(PDF-1+BCH-1)
|
||
(PDF-2+BCH-2)
|
||
|
||
|
||
≥ 3
|
||
≤ 2
|
||
≤ 1
|
||
Message
|
||
is
|
||
complete
|
||
but
|
||
unconfirmed.
|
||
Process, set bits
|
||
113 to 144 all to
|
||
“1”, and send alert
|
||
to MCC.
|
||
Message is complete, if
|
||
unconfirmed set bits
|
||
113-144 all to “1”.
|
||
Select: (i) confirmed
|
||
MRC, or (ii) MRV;
|
||
and send alert to MCC.
|
||
Message
|
||
is
|
||
complete,
|
||
if
|
||
unconfirmed set bits 113-144
|
||
all
|
||
to
|
||
“1”.
|
||
Select:
|
||
(i)
|
||
confirmed
|
||
MRC,
|
||
(ii)
|
||
confirmed MRV, or (iii)
|
||
MRV; and send alert to MCC.
|
||
≥ 2
|
||
Message is valid,
|
||
incomplete.
|
||
Process, set bits
|
||
113 to 144 all to
|
||
“1”, and send alert
|
||
to MCC.
|
||
Message
|
||
is
|
||
valid,
|
||
incomplete, set bits
|
||
113-144 all to “1”.
|
||
Select MRV and send
|
||
alert to MCC.
|
||
Message is valid, incomplete,
|
||
set bits 113-144 all to “1”.
|
||
Select: (i) confirmed MRC,
|
||
(ii) confirmed MRV, or (iii)
|
||
MRV; and send alert to MCC.
|
||
|
||
≤ 1
|
||
Suppress message.
|
||
Message is complete if
|
||
first
|
||
protected
|
||
data
|
||
field is confirmed.
|
||
Select: (i) confirmed
|
||
complete, or (ii) MRV
|
||
with bits 113-144 all
|
||
set to “1”, and send
|
||
alert to MCC; or (iii)
|
||
suppress if no message
|
||
is valid.
|
||
Message is complete if first
|
||
protected
|
||
data
|
||
field
|
||
is
|
||
confirmed.
|
||
Select: (i) confirmed MRC, or
|
||
(ii) confirmed MRV, or (iii)
|
||
MRV, and send alert to MCC;
|
||
or (iv) process according to
|
||
multiple
|
||
invalid
|
||
beacon
|
||
message processing if no
|
||
message is valid.
|
||
≥ 2
|
||
Suppress message.
|
||
Message is valid if first
|
||
protected data field is
|
||
confirmed.
|
||
Select: (i) MRV with
|
||
bits 113-144 all set to
|
||
“1”, and send alert to
|
||
MCC; or (ii) suppress
|
||
if no message is valid.
|
||
Message is valid if first
|
||
protected
|
||
data
|
||
field
|
||
is
|
||
confirmed.
|
||
Select: (i) confirmed MRC, or
|
||
(ii) confirmed MRV, or (iii)
|
||
MRV, and send alert to MCC;
|
||
or (iv) process according to
|
||
multiple
|
||
invalid
|
||
beacon
|
||
message processing if no
|
||
message is valid.
|
||
> 3
|
||
any
|
||
Suppress message.
|
||
Suppress message.
|
||
Process according to multiple
|
||
invalid
|
||
beacon
|
||
message
|
||
processing.
|
||
Notes: MRC = most recent complete message, MRV = most recent valid message.
|
||
**
|
||
A beacon message with any errors in fixed bits 107-110 or 107-109 shall be processed as
|
||
if it had more than 3 errors in (PDF-1 + BCH-1).
|
||
|
||
4-8
|
||
|
||
4.2.5.3 Multiple Invalid Beacon Message Processing (e.g. Miscoded Beacons)
|
||
If, after performing BCH error correction of all messages pertaining to the same beacon event, the
|
||
LEOLUT does not detect a valid message but detects three or more messages that fail the validation
|
||
described in section 4.2.4 and have identical bits 25 to 85, the LEOLUT shall perform the Doppler
|
||
processing described in section 4.2.7 and use one of the messages for inclusion in the alert
|
||
transmitted to the MCC. The LEOLUT shall set bits 113 to 144 all to “1”.
|
||
4.2.6
|
||
LEOLUT Time and Frequency Requirements
|
||
4.2.6.1 Time and Frequency Calculation for the SARP Channel
|
||
The information in the frequency data field must be converted to obtain the actual frequency value.
|
||
For Cospas and Sarsat satellites, this conversion is specified in document C/S T.003 (LEOSAR
|
||
space segment description). Specifically, for the Sarsat satellites, this conversion requires
|
||
knowledge of the frequency of the on-board Ultra Stable Oscillator (USO) as well as one of the
|
||
recent rollover times of the onboard counter.
|
||
The information in the time data field must be converted to actual UTC time value. The conversion
|
||
is specified in document C/S T.003 (LEOSAR space segment description). Specifically, for the
|
||
Sarsat satellites, the USO frequency value and the epoch of reset to zero of the SARP counter
|
||
(i.e., the roll over time), are required. These values can either be obtained from the MCC or
|
||
calculated internally by the LEOLUT. Prior to computing beacon locations by Doppler processing,
|
||
the LEOLUT must adjust the time data in each data point received from the SARP, in order to
|
||
make it correspond to the same instant as the frequency data. Hence, the LEOLUT must add 60
|
||
ms to the time data received from the Sarsat SARP instruments (since the time tag is synchronised
|
||
to the beginning of the 120 ms frequency measurement interval).
|
||
In the event that the Sarsat SARP instrument is reactivated (as described in document C/S A.001,
|
||
section 3), the roll over time is reset without regard to the previous roll over time. Therefore, the
|
||
LEOLUT shall use the SARP TCAL data from the associated MCC to initialize the LEOLUT
|
||
SARP TCAL data without regard to the previous SARP TCAL data at the LEOLUT.
|
||
For the Cospas satellites, the LEOLUT must add 100 ms to the time data received from the Cospas
|
||
SARP instruments (since the time tag is synchronised to the beginning of the 200 ms frequency
|
||
measurement interval). The time data in Cospas satellites is ahead of UTC by 2h 59min 59sec.
|
||
Parity checks shall be performed on the Doppler measurement field and/or the time field in the
|
||
downlink (see C/S T.003). Data that fails a parity check shall not be used in the Doppler processing
|
||
to compute the beacon location. Data points received by the LEOLUT which have severely
|
||
corrupted time or frequency values shall not be used in computing the Doppler position.
|
||
The frequency data has an "even" parity bit inserted by the SARP, which would indicate if an odd
|
||
number (one, three, five, etc.) of bit errors were present in the frequency data received by the
|
||
LEOLUT, but an even number of bit errors cannot be detected by this means.
|
||
|
||
4-9
|
||
|
||
4.2.6.2 Time and Frequency Measurements in the SARR Channel
|
||
The G-SARP shall measure the time and Doppler frequency to the accuracy required to satisfy the
|
||
location accuracy requirements specified in section 5.
|
||
4.2.6.3 Time and Frequency Requirements for Combined LEO/GEO Processing
|
||
The time and frequency information provided by the LEOSAR and GEOSAR systems shall be of
|
||
sufficient accuracy to satisfy the location accuracy requirements specified in section 5.
|
||
Differences in LEOSAR and GEOSAR satellite equipment may cause frequency biases associated
|
||
with the measurements of the 406 MHz beacon frequency. Using the LEOSAR data that it
|
||
generates, along with the GEOSAR data that it receives from a GEOLUT, the LEOLUT shall
|
||
normalize the frequency measurements from different sources without the need for a reference
|
||
beacon in the LEOLUT local coverage area. The 406 MHz SARR frequency calibration offset
|
||
data distributed in the SIT 510 messages may be used to adjust 406 MHz SARR frequency
|
||
measurements.
|
||
4.2.7
|
||
Doppler Processing and Validation
|
||
Except for combined LEO/GEO processing described below, the LEOLUT shall calculate Doppler
|
||
locations only from data points associated with the same beacon event (i.e., all the data points
|
||
generated from the same satellite pass of the beacon). The LEOLUT shall calculate Doppler
|
||
locations for all beacon events where the LEOLUT has received data points from three (3) or more
|
||
discrete beacon transmissions that satisfy the criteria defined below. It shall not produce Doppler
|
||
locations where the LEOLUT has received data points from less than three (3) discrete beacon
|
||
transmissions.
|
||
Also, the LEOLUT is not required to compute a Doppler location estimate for an autonomous
|
||
distress tracking ELT(DT) beacon. If a Doppler location estimate is generated for an ELT(DT)
|
||
beacon, it shall not be required to satisfy the associated performance requirements of section 5.
|
||
For combined LEO/GEO processing, the LEOLUT shall only use GEOSAR data that satisfies the
|
||
requirements detailed in document C/S T.009 and in section 4.2.7.5, and LEOSAR data points
|
||
associated with the same beacon event. The LEOLUT may only perform combined LEO/GEO
|
||
processing when it receives at least two (2) and no more than six (6) LEOSAR data points that
|
||
satisfy the criteria defined in section 4.2.7.1.
|
||
4.2.7.1 Criteria for Selection of Data Points Used in Doppler Processing
|
||
As a minimum, at least one of the following criteria shall be satisfied by the LEOSAR data points
|
||
used to compute a Doppler location:
|
||
|
||
4-10
|
||
|
||
data points whose associated messages satisfy the beacon message validation
|
||
requirements detailed in section 4.2.4;
|
||
data points whose associated messages are invalid but whose PDF-1 match the
|
||
PDF-1 of at least one valid message from the same beacon event; and
|
||
in cases where there are no valid messages obtained for the beacon event, the data
|
||
points associated with three (3) or more invalid messages that have identical bits
|
||
25 to 85.
|
||
4.2.7.2 Criteria for Rejection of Data Points for Doppler Processing
|
||
The time data on SARP-1 instruments is not covered by a parity bit (on SARP-2 a parity check is
|
||
available), nor is it protected by the BCH code, consequently time data may be erroneous. In view
|
||
of this, the LEOLUT shall detect and reject data points having time or frequency values that are
|
||
beyond certain physical limits, based upon the following:
|
||
the sequence and spacing of the data points;
|
||
the maximum possible rate of Doppler frequency shift;
|
||
the direction of frequency shift due to Doppler; and
|
||
the overall maximum Doppler shift on a satellite pass.
|
||
4.2.7.3 Combining Global and Local SARP Data Points in Doppler Locations
|
||
The LEOLUT shall use both local and global-mode data points from the same beacon event,
|
||
received from the same satellite pass, to calculate the Doppler location. In cases where the
|
||
LEOLUT has used data points from both local and global-modes generated from the same beacon
|
||
transmission, the resulting alert to the MCC shall only report the number of discrete beacon
|
||
transmissions used in the Doppler calculation (i.e., if the LEOLUT received both a global and
|
||
local-mode data point for the same beacon transmission, this would be counted as a single data
|
||
point for the purposes of reporting the number of data points which comprise the solution).
|
||
The local/global flag set by the LEOLUT for transmission to the MCC is used to indicate if the
|
||
reported location has been obtained from the local-mode or from the global-mode of operation. If
|
||
the 406 MHz location is a mixture of global and local-mode data, and the time of the first data
|
||
point is before the time of acquisition of the satellite downlink signal (AOS) by the LEOLUT, the
|
||
local/global flag shall be set as global.
|
||
4.2.7.4 Combining SARR and SARP Data Points in Doppler Locations
|
||
The LEOLUT may use a combination of SARR and SARP data points from the same beacon event,
|
||
received from the same satellite pass, to calculate Doppler locations. In addition, the LEOLUT
|
||
may use both the SARR and SARP data points associated with the same beacon transmission to
|
||
calculate Doppler locations. However, if this technique is used, the resulting alert to the MCC
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
4-11
|
||
|
||
shall only report the number of discrete beacon transmissions used in the Doppler calculation
|
||
(i.e., if the LEOLUT received and used both SARR and SARP data points for a given beacon
|
||
transmission, this would be counted as a single data point for the purpose of reporting the number
|
||
of data points which comprise the solution). The process of combining SARR and SARP data
|
||
points shall not adversely affect the quality of the alert (i.e., location accuracy, ambiguity
|
||
resolution, or quality/confidence of the identification associated with the alert).
|
||
4.2.7.5 Combining LEOSAR Data Points with GEOSAR Data in Doppler
|
||
Processing
|
||
Combined LEO/GEO processing in the LEOLUT requires individual burst data from the GEOSAR
|
||
system with time accuracy sufficient to provide point-to-point matching, and frequency accuracy
|
||
of 2 Hz.
|
||
The time and frequency information associated with the GEOSAR data messages shall be used to
|
||
determine the beacon frequency stability. For the purpose of combined LEO/GEO processing,
|
||
a beacon frequency is stable if the standard deviation of the calibrated GEOSAR frequency
|
||
measurements taken before and including the last LEOSAR data point is less than 2 Hz.
|
||
If the beacon frequency is stable, the time difference between the LEOSAR and GEOSAR data
|
||
points used for combined processing shall not exceed 30 minutes. If the beacon frequency is
|
||
unstable, the LEOLUT may perform combined LEO/GEO processing provided two (2) or more
|
||
GEOSAR data points match with the available LEOSAR data points. In cases where the stability
|
||
or instability of the beacon frequency cannot be determined the LEOLUT shall not perform
|
||
combined LEO/GEO processing.
|
||
The alert message transmitted to the MCC for locations produced by combined LEO/GEO
|
||
processing shall indicate the number of LEOSAR data points and the sources of the GEOSAR data
|
||
points (i.e., GEOLUT(s) and GEOSAR satellite(s)) used to compute the Doppler location. The
|
||
alert message transmitted to the MCC shall also include an indication of whether the Doppler
|
||
location was produced from a stable or unstable beacon frequency.
|
||
4.2.7.6 Validation of Doppler Locations
|
||
The LEOLUT, after performing any iterative process to select data points, shall not produce
|
||
Doppler solutions where:
|
||
the solutions are outside the footprint of the satellite when the satellite was at its
|
||
closest point to the beacon (TCA);
|
||
the TCA of any solution is separated by more than 12 minutes from any of the
|
||
LEOSAR data points used; and
|
||
for minimum point solutions, the frequency of the data points measured by the
|
||
LEOLUT increases.
|
||
Alerts failing any of these criteria shall be reported as Doppler unlocated alerts.
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
4-12
|
||
|
||
4.2.7.7 Beacon Message Assigned to the Alert
|
||
The beacon message assigned to a Doppler alert is obtained from the beacon message processing
|
||
described in section 4.2.5.
|
||
4.2.8
|
||
Transmission of Alert Data to MCC
|
||
The LEOLUT shall transmit all the necessary data to enable the associated MCC to satisfy the
|
||
requirements of documents C/S A.002 (SID) and C/S A.005 (MCC specification).
|
||
The LEOLUT shall transmit solution data to its associated MCC as required by the QMS
|
||
continuous monitoring and objective assessment process described in section 2 of System
|
||
document C/S A.003 (system monitoring and reporting).
|
||
– END OF SECTION 4 –
|
||
|
||
5-1
|
||
|
||
5.
|
||
PERFORMANCE REQUIREMENTS
|
||
The performance requirements defined in the following sections establish measurable
|
||
performance criteria that a LEOLUT must meet before it can be integrated into the Cospas-
|
||
Sarsat System and commissioned by the Cospas-Sarsat Council.
|
||
LEOLUT performance shall be measured using the LEOLUT certification and commissioning
|
||
test scenarios specified in C/S T.005.
|
||
Two sets of performance criteria (nominal and marginal) are used to characterise the location
|
||
accuracy, ambiguity resolution and error ellipse calculations. Solutions obtained from Doppler
|
||
curves with four (4) or more 406 MHz data points, which bracket the time of closest approach
|
||
(TCA) and have an absolute value of cross track angle (¦CTA¦) between one (1) and twenty (20)
|
||
degrees, shall be considered nominal solutions. All other Doppler solutions shall be considered
|
||
marginal solutions.
|
||
In the case of combined LEO/GEO processing it is possible to calculate Doppler locations using
|
||
two LEOSAR data points supplemented with information from the GEOSAR system. Such
|
||
two-point solutions are a subset of marginal solutions referred to as minimum point solutions.
|
||
5.1.1
|
||
RF Signal Margin
|
||
LEOLUT performance shall be maintained during periods of short-term fading as detailed in
|
||
Annex A.
|
||
5.1.2
|
||
Processing Time
|
||
The LEOLUT shall be able to process satellite passes and send alert data to the MCC in fewer
|
||
than fifteen (15) minutes after loss of the satellite signal (LOS) for 99% of all passes. This
|
||
processing requirement applies to all Doppler solution processing combinations implemented in
|
||
the LEOLUT.
|
||
5.1.3
|
||
Orbit Determination
|
||
The LEOLUT shall be able to estimate the position of the satellite to within two (2) kilometres
|
||
for the processing of all data.
|
||
However, in the event of a scheduled satellite manoeuvre (as described in document C/S A.001),
|
||
the LEOLUT may not be able to maintain accurate orbital elements. When such an event
|
||
changes the satellite position by more than two (2) kilometres since the previously tracked pass,
|
||
this accuracy requirement is waived:
|
||
prior to the receipt of post-manoeuvre orbital elements for solutions with data
|
||
occurring after the start of the manoeuvre, and
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
5-2
|
||
|
||
after the receipt of post-manoeuvre orbital elements for solutions with data
|
||
occurring before the end of the manoeuvre.
|
||
5.1.4
|
||
Ambiguity Resolution
|
||
The ambiguity resolution probability is an estimate of which of the two solutions is correct for
|
||
a particular Doppler curve. This probability shall be provided for each of the two solutions and
|
||
their sum shall be unity (1.00). The solution with the highest probability shall be identified as
|
||
the “A” solution, and the other shall be designated as the “B” solution.
|
||
5.1.5
|
||
Error Ellipse
|
||
An error ellipse shall be provided for every location. The error ellipse shall define the area
|
||
within which there is a fifty percent (50%) probability that the actual location of the beacon is
|
||
contained.
|
||
5.2.1
|
||
Data Recovery
|
||
The LEOLUT shall be able to acquire and demodulate the PDS data with a bit error rate not
|
||
exceeding one part in ten raised to the power six, at antenna elevation angles of five (5) degrees
|
||
or greater. The PDS link margin shall be a positive number determined by national authorities
|
||
in accordance with the guidelines in Annex A.
|
||
Each frame of twenty-five (25) or fifty (50) 24-bit words begins with a synchronisation word,
|
||
which is the hexadecimal characters 42BB1F. For a complete memory dump cycle, the
|
||
LEOLUT shall not lose more than one (1) frame.
|
||
5.2.2
|
||
Time and Frequency Calculation
|
||
The LEOLUT shall use the formula in the document C/S T.003 (LEOSAR space segment
|
||
description) to calculate the frequency value of 406 MHz transmitted signals to the accuracy
|
||
measured by the satellite. During the process of calculating the frequency, the LEOLUT shall
|
||
carry sufficient significant digits to provide at least 1 millihertz resolution.
|
||
The LEOLUT shall calculate the beacon message time-tags to a resolution of one millisecond.
|
||
5.2.3
|
||
Beacon Capacity
|
||
The LEOLUT shall be able to process PDS data received during a single satellite pass from at
|
||
least 90 active beacons in the local-mode and at least 200 beacons in the global mode.
|
||
5.2.4
|
||
Location Accuracy
|
||
At least ninety five percent (95%) of nominal solutions shall be accurate to within five (5) km,
|
||
and ninety eight (98%) of locations accurate to within ten (10) km.
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
5-3
|
||
|
||
For marginal solutions, a minimum of sixty percent (60%) of locations shall be accurate to within
|
||
(5) km, and eighty percent (80%) of locations accurate to within twenty (20) km.
|
||
These accuracy requirements apply for beacons that meet the requirements of document
|
||
C/S T.001 (beacon specification), except for ELT(DT)s.
|
||
5.2.5
|
||
Ambiguity Resolution
|
||
For nominal solutions the ambiguity resolution shall be correct for at least ninety percent (90%)
|
||
of the solutions. For marginal solutions the ambiguity resolution shall be correct at least 60% of
|
||
the time. This requirement applies for beacons satisfying the specifications for Cospas-Sarsat
|
||
406 MHz distress beacons as detailed in document C/S T.001, except for ELT(DT)s.
|
||
5.3.1
|
||
Signal Sensitivity
|
||
The signal sensitivity threshold is the C/No level at which the G-SARP will correctly process
|
||
90% of individual beacon messages, where C/No is the ratio of the unmodulated carrier power
|
||
to noise power density in dB-Hz.
|
||
The LEOLUT signal sensitivity shall be better than 36 dB-Hz.
|
||
5.3.2
|
||
Beacon Message Throughput
|
||
Beacon message throughput is a measure of the LEOLUT’s ability to correctly process and
|
||
obtain valid beacon messages from beacon signals which satisfy the specifications for Cospas-
|
||
Sarsat 406 MHz distress beacons as detailed in document C/S T.001.
|
||
The LEOLUT shall maintain a throughput rate of at least 75% for all beacons satisfying
|
||
C/S T.001 requirements when calculated between the first and last beacon messages for beacon
|
||
events meeting the criteria for nominal solutions described in section 5.1 above.
|
||
5.3.3
|
||
Probability of Doppler Location
|
||
The LEOLUT shall be able to obtain beacon messages and locate 406 MHz beacons within the
|
||
LEOLUT’s coverage area when there is 4 minutes of mutual visibility between the LEOLUT,
|
||
satellite and beacon, with the satellite at an elevation angle greater than 5 degrees with respect
|
||
to the LEOLUT and the beacon. In these cases the LEOLUT shall be able to calculate Doppler
|
||
locations with a probability of 95%.
|
||
5.3.4
|
||
Time and Frequency Calculation
|
||
The LEOLUT processing of SARR channel data must perform validity checks to prevent invalid
|
||
time and frequency values being used in Doppler processing as described in section 4.2.7. The
|
||
LEOLUT shall measure the time and frequency of data points, as received, to an accuracy better
|
||
than 10 ms and 350 millihertz respectively. The frequency measurement accuracy excludes
|
||
frequency bias that is constant over a period of 20 minutes.
|
||
|
||

|
||
|
||

|
||
|
||
5-4
|
||
|
||
5.3.5
|
||
Beacon Capacity
|
||
The LEOLUT must be able to detect and process at least ten active beacons within the field of
|
||
view of the satellite.
|
||
5.3.6
|
||
Location Accuracy
|
||
At least ninety five percent (95%) of nominal solutions shall be accurate to within five (5) km,
|
||
and ninety eight (98%) of locations accurate to within ten (10) km.
|
||
For marginal solutions, a minimum of sixty percent (60%) of locations shall be accurate to within
|
||
(5) km, and eighty percent (80%) of locations accurate to within twenty (20) km.
|
||
These accuracy requirements apply for beacons that meet the requirements of document
|
||
C/S T.001 (406 MHz beacon specification), except for ELT(DT)s.
|
||
5.3.7
|
||
Ambiguity Resolution
|
||
For nominal solutions, the ambiguity resolution shall be correct for at least ninety percent (90%)
|
||
of the solutions. For marginal solutions, the ambiguity resolution shall be correct at least 60%
|
||
of the time. This specification applies for beacons satisfying the specifications for Cospas-Sarsat
|
||
406 MHz distress beacons as detailed in document C/S T.001, except for ELT(DT)s.
|
||
5.3.8
|
||
Prevention of False Alerts Caused by Processing Anomalies
|
||
A mechanism shall be provided in the LEOLUT’s SARR channel processing to prevent the
|
||
transmission of false alerts caused by processing anomalies. The ratio of LEOLUT generated
|
||
false alerts caused by processing anomalies to actual alerts shall not exceed 1 x 10-4.
|
||
5.3.9
|
||
Processing Bandwidth
|
||
As a minimum the LEOLUT shall be capable of processing the signals of the 406 MHz beacons
|
||
defined in the document C/S T.001. Processing the 406.01 MHz to 406.09 MHz bandwidth
|
||
(i.e., 80 kHz) is required for all equipment commissioned after October 1998.
|
||
LEOLUTs which combine the results of SARP and SARR channels to produce alerts calculated
|
||
from a combination of both sources, shall satisfy all the specification requirements of each
|
||
channel independently (i.e., the SARP channel shall satisfy all the specifications detailed in
|
||
section 5.2 and the SARR channel shall satisfy all the specifications detailed in section 5.3).
|
||
Furthermore, the combined processing results shall satisfy the most stringent specifications of
|
||
either channel for the following performance parameters:
|
||
location accuracy; and
|
||
ambiguity resolution.
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
5-5
|
||
|
||
5.5.1
|
||
Nominal and Marginal Solutions
|
||
LEOLUTs which combine LEOSAR data points with data provided by the GEOSAR system to
|
||
produce alerts from a combination of both sources, shall satisfy the specification criteria of each
|
||
channel independently as well as any specific combined LEO/GEO processing requirements
|
||
detailed in this document. Furthermore, the combined LEO/GEO processing results in all the
|
||
possible combinations (i.e., GEOSAR/SARP/SARR, GEOSAR/SARP, GEOSAR/SARR) shall
|
||
satisfy the most stringent specifications of each channel for the following performance
|
||
parameters:
|
||
location accuracy; and
|
||
ambiguity resolution.
|
||
The probability of Doppler location shall not be degraded by combined LEO/GEO processing.
|
||
When only two data points are available, the processing does not have sufficient data to compute
|
||
an ambiguity resolution probability; the ambiguity resolution probability is always set to 50%.
|
||
For this reason, there is no specified requirement for ambiguity resolution of minimum point
|
||
solutions, and the requirement for marginal solutions is specified only for those marginal
|
||
solutions that are not minimum point solutions.
|
||
5.5.2
|
||
Location Accuracy for Minimum Point Solutions
|
||
In addition to the requirements detailed in section 5.5.1, for minimum point solutions, a
|
||
minimum of sixty percent (60%) of locations shall be accurate to within five (5) km, and eighty
|
||
percent (80%) of locations accurate to within twenty (20) km.
|
||
These accuracy requirements apply for beacons that meet the requirements of document
|
||
C/S T.001 (406 MHz beacon specification), except for ELT(DT)s.
|
||
– END OF SECTION 5 –
|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||

|
||
|
||
ANNEXES TO
|
||
COSPAS-SARSAT
|
||
LEOLUT
|
||
PERFORMANCE SPECIFICATION
|
||
AND DESIGN GUIDELINES
|
||
|
||
A-1
|
||
|
||
ANNEX A:
|
||
DESIGN GUIDELINES FOR DETERMINING THE DOWNLINK POWER BUDGET
|
||
FOR THE 406 MHZ SARP CHANNEL
|
||
A.1
|
||
Introduction
|
||
Administrations intending to acquire a Local User Terminal (LUT) to be used in the Cospas Sarsat
|
||
System should ensure that the station's antenna and RF subsystems will meet the Cospas-Sarsat
|
||
performance standards defined in documents C/S T.002 (LEOLUT specification) and C/S T.005
|
||
(LEOLUT commissioning standard). One way to determine this performance is to calculate the
|
||
downlink power budget for the 406 MHz SARP channel (i.e., the 2.4 kilobit per second Processed
|
||
Data Stream (PDS) channel) from the Cospas and Sarsat satellites. This annex provides guidance
|
||
for making these calculations. In addition, calculations not provided in this annex should be made
|
||
for the uplink and downlink of the other satellite channels.
|
||
A.2
|
||
Explanation of the downlink budget
|
||
The PDS is digital data produced onboard the satellite and transmitted on the downlink signal.
|
||
Because this is a digital data channel, it is important that the radio link between the satellite and
|
||
the processing equipment in the LEOLUT is of sufficient quality so as not to corrupt the received
|
||
data, which could lead to erroneous alert messages being produced or valid messages being lost.
|
||
The PDS channel shares the satellite downlink carrier with other Search and Rescue channels on
|
||
the satellite. There is a nominal ratio of the PDS power relative to the total transmitter power,
|
||
which is given as (PPDS/PT) in Table A.1, but this ratio can vary due to signal activity in the other
|
||
channels. This variation is included in the PDS short-term fading loss (Lf) in Table A.1.
|
||
It should be noted that, at various times during a satellite pass, transient signal activity in the uplink
|
||
channels produces not only short-term fading in the PDS channel but also carrier suppression of
|
||
about 20 dB for periods of up to 100 milliseconds.
|
||
The Cospas-Sarsat PDS channel is designed to provide reliable performance if the "bit error rate"
|
||
(BER) received at the LEOLUT is better than 10-6 (i.e., less than 1 bit error per million bits).
|
||
To ensure reliable reception of this PDS data, an analysis should be made on the antenna and RF
|
||
subsystems and the probable "bit error rate" computed. Such an analysis should include the
|
||
satellite parameters, the geometry between the moving satellite and the LEOLUT, the LEOLUT
|
||
location, local environment (e.g. site conditions, meteorological and ionospheric effects, noise and
|
||
interference sources, etc.) and the LEOLUT characteristics (e.g. antenna, RF system, receiver, bit
|
||
synchronizer, etc.).
|
||
|
||
A-2
|
||
|
||
A.3
|
||
Calculations
|
||
Table A.1 provides values for some of the parameters that could be used to calculate the downlink
|
||
power budget for the PDS channel. Administrations should also consider the following
|
||
atmospheric and design dependent losses and determine appropriate values for their LEOLUT
|
||
design and specific site location.
|
||
atmospheric propagation losses
|
||
=
|
||
antenna polarization mismatch
|
||
=
|
||
antenna pointing
|
||
=
|
||
demodulation
|
||
=
|
||
bit synchronizer
|
||
=
|
||
other
|
||
=
|
||
TOTAL LOSSES (Lo)=
|
||
The energy-per-bit-to-noise-density ratio (Eb/N0) of the PDS digital data stream (i.e., the primary
|
||
factor governing the BER of the data) can be calculated using the following equation and the values
|
||
given in Table A.1:
|
||
(Eb/N0)c = (e.i.r.p.) - (Lp + Lf + Lo) + (G/T) - (k) - (r) + (PPDS/PT) dB
|
||
where:
|
||
PPDS/PT
|
||
= [1 - exp(-βT2)] x (βPDS/βT)2 (numeric)
|
||
β T2
|
||
= β PDS2 + β4062
|
||
for Cospas and Sarsat satellites
|
||
βT
|
||
= modulation index of composite signal (radians rms)
|
||
βi
|
||
= modulation index of channel i (i= PDS 406) (radians rms)
|
||
Nominal modulation index values (radians rms) from C/S T.003 are:
|
||
Cospas
|
||
Sarsat
|
||
satellites
|
||
satellites
|
||
radians rms
|
||
β406
|
||
=
|
||
0.68
|
||
0.58\*
|
||
βPDS
|
||
=
|
||
0.32
|
||
0.39
|
||
βT
|
||
=
|
||
0.75
|
||
0.70
|
||
Using these modulation index values gives:
|
||
[PPDS/PT
|
||
= -11.1 dB
|
||
for Cospas satellites ]
|
||
* Viterbi, A.J., "Principles of Coherent Communication", McGraw Hill, New York, USA, 1966, pp 169-172.
|
||
|
||
A-3
|
||
|
||
= -9.2 dB
|
||
for Sarsat satellites†
|
||
Other variables in the equation are defined in Table A.1.
|
||
Theoretically, a value of (Eb/N0)th = 10.6 dB is necessary to achieve the required BER value of
|
||
10-6 in the PDS channel‡.
|
||
Solving the initial equation using values from Table A.1 shows that the difference between the
|
||
calculated value (Eb/N0)c and the theoretically required value (Eb/N0)th of 10.6 dB is the PDS link
|
||
margin:
|
||
PDS Link Margin =(Eb/N0)c - (Eb/N0)th
|
||
= (G/T) - Lo + 4.0 dB for Cospas
|
||
= (G/T) - Lo + 6.6 dB for Sarsat*
|
||
A.4
|
||
Summary
|
||
Administrations should ensure that their LEOLUT antenna G/T value, when combined with the
|
||
other losses, will provide a positive value PDS link margin
|
||
† Applicable for SARR-1 only
|
||
‡ for coherent detection of a biphase-phase-shift-keyed (BPSK) signal in a Gaussian noise channel, as defined in
|
||
communications textbooks, such as Spilker, J.J., "Digital Communications by Satellite", Prentice-Hall Inc., New
|
||
Jersey, USA, 1977, pp 31 32, (ISBN 0-13-214155-8).
|
||
|
||
A-4
|
||
|
||
Table A.1:
|
||
Downlink Power Budget Parameters for the Cospas and Sarsat Processed Data Stream (PDS) Channels
|
||
Parameter
|
||
Units
|
||
Cospas
|
||
Nominal
|
||
Sarsat
|
||
Nominal
|
||
Source
|
||
Carrier frequency
|
||
(MHz)
|
||
1544.5
|
||
1544.5
|
||
C/S T.003
|
||
Polarization (Left Hand Circular)
|
||
LHCP
|
||
LHCP
|
||
C/S T.003
|
||
Elevation angle
|
||
(degrees)
|
||
|
||
|
||
C/S T.002
|
||
Satellite altitude
|
||
(km)
|
||
|
||
|
||
C/S T.003
|
||
Satellite e.i.r.p
|
||
\*
|
||
(dBW)
|
||
6.2
|
||
7.1
|
||
C/S T.003
|
||
Slant range @ 5 degrees
|
||
(km)
|
||
|
||
|
||
Calculated from geometry
|
||
Free-space path loss (Lp)
|
||
(dB)
|
||
165.3
|
||
165.5
|
||
Calculated standard formula
|
||
Short-term fading loss (Lf)
|
||
(dB)
|
||
|
||
|
||
See text in section A.2
|
||
Other losses (Lo)
|
||
(dB)
|
||
Lo†
|
||
Lo
|
||
LUT design and site dependant
|
||
Antenna (G/T)‡
|
||
(dB)
|
||
G/T
|
||
G/T
|
||
LUT dsign dependant
|
||
Boltzmann constant (k)
|
||
(dBK-1)
|
||
-228.6
|
||
-228.6
|
||
Physical constant
|
||
Data rate factor @ 2.4 kbps (r)
|
||
(dBK-1Hz-1)
|
||
33.8
|
||
33.8
|
||
C/S T.003
|
||
Modulation loss (PPDS/PT)
|
||
(dB)
|
||
-11.1
|
||
-9.2
|
||
See text in section A-3
|
||
Desired maximum Bit Error Rate
|
||
(BER)
|
||
10-6
|
||
10-6
|
||
C/S T.002
|
||
Calculated (Eb/N0)c
|
||
(dB)
|
||
G/T-
|
||
L0+14.6
|
||
G/T-L0+17.2
|
||
Using above parameters
|
||
Theoretical (Eb/N0)th for BER of 10-6
|
||
(dB)
|
||
10.6
|
||
10.6
|
||
See footnote on page A-3
|
||
PDS Link Margin
|
||
(dB)
|
||
G/T-L0+4.0
|
||
G/T-L0+6.6
|
||
See text in section A-3
|
||
- END OF ANNEX A -
|
||
* Equivalent Isotropically Radiated Power
|
||
† see factors in previous list (page A-2)
|
||
‡ Antenna Gain-to-Noise Temperature Ratio, to include radome, if applicable, and cable losses
|
||
|
||
B-1
|
||
|
||
ANNEX B:
|
||
BEACON MESSAGE PROCESSING
|
||
Figure B. 1: Beacon Message Processing (Long Message format)
|
||
NOTES: MRC = most recent complete
|
||
MRV = most recent valid message
|
||
PVM = previous valid message
|
||
Start from last message
|
||
of beacon event
|
||
Is
|
||
Message
|
||
Valid
|
||
Yes
|
||
No
|
||
Yes
|
||
Yes
|
||
BCH-2
|
||
pass?
|
||
No
|
||
Message is most recent
|
||
valid (MRV) &
|
||
incomplete
|
||
Set bits 113-144 all to “1”
|
||
Select previous
|
||
message
|
||
Message is most
|
||
recent complete
|
||
(MRC)
|
||
Previous message
|
||
exists?
|
||
Invalid Message
|
||
Processing
|
||
No
|
||
Search for PDF-1 that matches with
|
||
PDF-1 of MRV
|
||
No
|
||
Send MRV with
|
||
bits 113-144 all set to “1”
|
||
No
|
||
Previous message
|
||
exists?
|
||
Yes
|
||
Yes
|
||
Previous message
|
||
exists?
|
||
No
|
||
Search for match between
|
||
previous complete
|
||
messages
|
||
Send most recent
|
||
complete messages
|
||
that match
|
||
Yes
|
||
2 other
|
||
previous complete
|
||
messages
|
||
match?
|
||
Search for most recent
|
||
valid (MRV) message
|
||
Search for match
|
||
with previous
|
||
complete messages
|
||
Yes
|
||
Yes
|
||
2 other
|
||
previous complete
|
||
messages
|
||
match?
|
||
1 previous
|
||
complete message
|
||
matches with
|
||
MRC?
|
||
No
|
||
No
|
||
Send MRV message with
|
||
bits 113-144 all set to “1”
|
||
Send PVM that match,
|
||
with bits 113-144 all set to “1”
|
||
Previous
|
||
valid message (PVM)
|
||
exists ?
|
||
No
|
||
PDF-1 match with
|
||
MRV?
|
||
No
|
||
Yes
|
||
Yes
|
||
PDF-1 match with
|
||
PVM?
|
||
No
|
||
Yes
|
||
|
||
B-2
|
||
|
||
Figure B. 2: Beacon Message Processing (Short Message format)
|
||
NOTES: MRV = most recent valid message
|
||
PVM = previous valid message
|
||
Start from last message
|
||
of beacon event
|
||
Is
|
||
Message
|
||
Valid
|
||
Yes
|
||
No
|
||
Yes
|
||
No
|
||
Previous message
|
||
exists?
|
||
Yes
|
||
Select previous
|
||
message
|
||
Message is most
|
||
recent valid
|
||
(MRV)
|
||
Previous message
|
||
exists?
|
||
Invalid Message
|
||
Processing
|
||
No
|
||
Search for PDF-1 that match
|
||
with PDF-1 of MRV
|
||
Send MRV message
|
||
with bits 113-144 all set to “0”
|
||
Send PVM that match,
|
||
with bits 113-144 all set to “0”
|
||
previous
|
||
valid message(PVM)
|
||
exists ?
|
||
No
|
||
PDF-1 match with
|
||
MRV?
|
||
No
|
||
Yes
|
||
Yes
|
||
PDF-1 match with
|
||
PVM?
|
||
No
|
||
Yes
|
||
|
||
B-3
|
||
|
||
Figure B. 3: Examples of Encoded Data Selection for Multiple Message Beacon
|
||
Events - Long Message Format
|
||
Note: Protected data fields that do not pass BCH correction are shaded. The following examples
|
||
illustrate the selection logic but may not be typical of normal operating conditions.
|
||
First Message Complete
|
||
M.1
|
||
Second Message Invalid
|
||
M.2
|
||
Third Message Complete
|
||
M.3
|
||
Fourth Message Complete
|
||
M.4
|
||
Example 1:
|
||
M.4 is the most recent complete message, but is not confirmed by matching with a
|
||
previous complete message. M.3 is the most recent complete message that matches
|
||
another complete message (M.1). Therefore, M.3 shall be sent to the MCC.
|
||
First Message Complete
|
||
M.1
|
||
Second Message Complete
|
||
M.2
|
||
Third Message Invalid
|
||
M.3
|
||
Fourth Message Complete
|
||
M.4
|
||
Fifth Message Valid,
|
||
M.5
|
||
Incomplete
|
||
Sixth Message Complete
|
||
M.6
|
||
Example 2:
|
||
M.6 is the most recent complete message that matches another complete message
|
||
(M.4). Therefore, M.6 shall be sent to the MCC.
|
||
Example 3:
|
||
Same set of messages as above, but without the sixth message. In that case, The
|
||
most recent complete message is M.4, but no previous complete message match with M.4. No
|
||
other previous complete messages match (M.1 and M.2 have different PDF-2). The most recent
|
||
valid message is M.5. M.4 (PDF-1) matches with M.5. Therefore, M.5 shall be sent with bits
|
||
113 to 114 set to “1”.
|
||
M.1 (PDF-1+BCH-1)
|
||
IDENT+XXX+AAA
|
||
M.2 (PDF-1+BCH-1)
|
||
IDENT+YYY+BBB
|
||
M.3 (PDF-1+BCH-1)
|
||
IDENT+XXX+AAA
|
||
M.4 (PDF-1+BCH-1)
|
||
IDENT+ZZZ+CCC
|
||
M.1 (PDF-2+BCH-2)
|
||
xxx+aaa
|
||
M.2 (PDF-2+BCH-2)
|
||
yyy+bbb
|
||
M.3 (PDF-2+BCH-2)
|
||
xxx+aaa
|
||
PDF-2 / M.3
|
||
M.4 (PDF-2+BCH-2)
|
||
zzz+ccc
|
||
M.1 (PDF-1+BCH-1)
|
||
IDENT+XXX+AAA
|
||
M. 3(PDF-1+BCH-1)
|
||
IDENT+YYY+BBB
|
||
M.4 (PDF-1+BCH-1)
|
||
IDENT+ZZZ+CCC
|
||
M.5 (PDF-1+BCH-1)
|
||
IDENT+ZZZ+CCC
|
||
M.1 (PDF-2+BCH-2)
|
||
xxx+aaa
|
||
M.3 (PDF-2+BCH-2)
|
||
111+111
|
||
M.4 (PDF-2+BCH-2)
|
||
zzz+ccc
|
||
M.5 (PDF-2+BCH-2)
|
||
111+111
|
||
M.2 (PDF-2+BCH-2)
|
||
yyy+bbb
|
||
M.6 (PDF-2+BCH-2)
|
||
zzz+ccc
|
||
M.2 (PDF-1+BCH-1)
|
||
IDENT+XXX+AAA
|
||
M.6 (PDF-1+BCH-1)
|
||
IDENT+ZZZ+CCC
|
||
|
||
B-4
|
||
|
||
Figure B. 4: Examples of Encoded Data Selection for Multiple Message Beacon
|
||
Events - Long Message Format - (continued)
|
||
First Message Valid,
|
||
M.1
|
||
Incomplete
|
||
Second Message Invalid
|
||
M.2
|
||
Third Message Complete
|
||
M.3
|
||
Fourth Message Complete
|
||
M.4
|
||
Example 4: M.4 is the most recent complete message, but is not confirmed by matching with a previous
|
||
complete message. No other previous complete messages match (M.2 is invalid and M.1
|
||
incomplete). The most recent valid message is M.4, but is not confirmed by matching the
|
||
PDF-1 of a prior message. M.3 is a previous valid message for which PDF-1 matches another
|
||
previous message (M.1). Therefore, M.3 shall be sent to the MCC, with bits 113 to 144 set
|
||
to “1”.
|
||
First Message Complete
|
||
M.1
|
||
Second Message Complete
|
||
M.2
|
||
Third Message Invalid
|
||
M.3
|
||
Fourth Message Complete
|
||
M.4
|
||
Fifth Message Invalid,
|
||
M.5
|
||
Incomplete
|
||
Sixth Message Valid,
|
||
M.6
|
||
Incomplete
|
||
Example 5: M.4 is the most recent complete message but is not confirmed by matching with a
|
||
previous complete message. M.2 is a previous complete message that match with
|
||
another complete message (M.1). Therefore, M.2 shall be sent to the MCC.
|
||
Example 6: Same set of messages, but assuming that M.1 is invalid. Then the previous complete
|
||
message M.2 is not confirmed by matching, and M.6 is the most recent valid message
|
||
whose PDF-1 matches that of another message (M.5). Therefore, M.6 shall be sent to
|
||
the MCC, with bits 113 to 144 set to “1”.
|
||
M.1 (PDF-1+BCH-1)
|
||
IDENT+XXX+AAA
|
||
M.1 (PDF-1+BCH-1)
|
||
IDENT+XXX+AAA
|
||
M.2 (PDF-1+BCH-1)
|
||
IDENT+YYY+BBB
|
||
M.3 (PDF-1+BCH-1)
|
||
IDENT+XXX+AAA
|
||
M.3 (PDF-1+BCH-1)
|
||
IDENT+YYY+BBB
|
||
M.4 (PDF-1+BCH-1)
|
||
IDENT+ZZZ+CCC
|
||
M.4 (PDF-1+BCH-1)
|
||
IDENT+ZZZ+CCC
|
||
M.1 (PDF-2+BCH-2)
|
||
111+111
|
||
M.1 (PDF-2+BCH-2)
|
||
xxx+aaa
|
||
M.2 (PDF-2+BCH-2)
|
||
111+111
|
||
M.3 (PDF-2+BCH-2)
|
||
xxx+aaa
|
||
M.3 (PDF-2+BCH-2)
|
||
111+111
|
||
M.4 (PDF-2+BCH-2)
|
||
zzz+ccc
|
||
M.4 (PDF-2+BCH-2)
|
||
zzz+ccc
|
||
M.5 (PDF-2+BCH-2)
|
||
111+111
|
||
M.2 (PDF-2+BCH-2)
|
||
xxx+aaa
|
||
M.6 (PDF-2+BCH-2)
|
||
111+111
|
||
M.2 (PDF-1+BCH-1)
|
||
IDENT+XXX+AAA
|
||
M.6 (PDF-1+BCH-1)
|
||
IDENT+∆∆∆+DDD
|
||
M.5 (PDF-1+BCH-1)
|
||
IDENT+∆∆∆+NNN
|
||
|
||
B-5
|
||
|
||
Figure B. 5: Examples of Encoded Data Selection for Multiple Message
|
||
Beacon Events - Short Message Format
|
||
- END OF ANNEX B -
|
||
First Message Valid
|
||
M.1
|
||
Second Message Valid
|
||
M.2
|
||
Third Message Invalid
|
||
M.3
|
||
Fourth Message Valid
|
||
M.4
|
||
Example 1: M.4 is the most recent valid/complete message, but is not confirmed by matching. M.2
|
||
is the previous valid/complete message confirmed by matching with M.1. M.2 shall
|
||
be sent to the MCC, with bits 113 to 144 set to “0”.
|
||
Example 2: Same set of messages, but assuming M.1 is invalid. No valid/complete messages can
|
||
be confirmed by matching and M.4 is the most recent valid message that shall be sent
|
||
to the MCC, with bits 113 to 144 set to “0”.
|
||
M.1 (PDF-1+BCH-1)
|
||
IDENT+XXX+AAA
|
||
M.2 (PDF-1+BCH-1)
|
||
IDENT+XXX+AAA
|
||
M.3 (PDF-1+BCH-1)
|
||
IDENT+YYY+BBB
|
||
M.4 (PDF-1+BCH-1)
|
||
IDENT+ZZZ+CCC
|
||
|
||
C-1
|
||
|
||
ANNEX C:
|
||
OPTIONAL PROCESSING OF INTERFERENCE USING THE
|
||
406 MHZ REPEATER BAND
|
||
C.1
|
||
Introduction
|
||
This annex describes how the 406 MHz repeater system aboard some of the Cospas-Sarsat satellites
|
||
can be used by LEOLUTs to perform interference monitoring of the 406 MHz band. The repeater
|
||
can be used, only in the local-mode coverage area, to detect and locate 406 MHz interference in the
|
||
406 MHz band.
|
||
C.2
|
||
Functional Description
|
||
To detect and locate interfering signals in the 406 MHz band (i.e., non-beacon signals), the approach
|
||
needed is different than for beacon signals because interferers do not transmit in the same format as
|
||
a beacon signal. Interferers generally transmit continuous signals for several seconds, minutes, or
|
||
even hours, compared to the one-half second burst of a beacon signal. Processing such interfering
|
||
signals produces a long Doppler curve which can be used to compute the location. No identification
|
||
code can be extracted from an interfering signal, since its modulation, if any, would not be in the
|
||
correct format.
|
||
C.3
|
||
Operational Recommendations
|
||
406 MHz interference monitoring is encouraged for all LEOLUTs on a best effort basis. As much
|
||
data as possible should be collected and recorded.
|
||
When a new 406 MHz interferer is detected on at least a few satellite passes, the LEOLUT/MCC
|
||
operator is encouraged to inform the appropriate Search and Rescue authorities in the area of the
|
||
interferer (i.e., locations and times) and to periodically report such interference to the ITU using
|
||
national procedures and also to include such information in their annual status reports to Cospas-
|
||
Sarsat. Detailed instructions for interference reporting are included in Cospas-Sarsat document
|
||
C/S A.003.
|
||
C.4
|
||
Performance Specification
|
||
C.4.1
|
||
Processing Time
|
||
Additional processing of the 406 MHz repeater band shall not significantly affect the overall
|
||
processing time of the PDS channels.
|
||
C.4.2
|
||
Location Accuracy
|
||
Under the following signal characteristics:
|
||
linear frequency drift is less than forty (40) Hz per minute, and
|
||
|
||

|
||
|
||
C-2
|
||
|
||
a minimum of four (4) minutes of data which includes the TCA, is received
|
||
by the LEOLUT,
|
||
the location accuracy should be better than twenty (20) km for at least seventy percent (70%) of the
|
||
locations.
|
||
- END OF DOCUMENT -
|
||
|
||

|
||
|
||
Cospas-Sarsat Secretariat
|
||
1250 René-Lévesque Blvd. West, Suite 4215, Montreal (Quebec) H3B 4W8 Canada
|
||
Telephone: +1 514 500 7777
|
||
Fax: +1 514 500 7996
|
||
Email: mail@cospas-sarsat.int
|
||
Website: http://www.cospas-sarsat.int |