Ryan Malloy 4ed92efd69 refactor: move spec references out of published site
Cospas-Sarsat specification summaries moved to reference/ for internal
use only. Links updated to point to official cospas-sarsat.int site.

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

81 KiB
Raw Permalink Blame History

title description sidebar documentId series seriesName documentType isLatest issue revision documentDate originalTitle
T002: C/S T.002 - Issue 5 - Rev. 1 Official Cospas-Sarsat T-series document T002
badge
text variant
T note
T002 T Technical specification true 5 1 March 2022 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


COSPAS-SARSAT LEOLUT PERFORMANCE SPECIFICATION AND DESIGN GUIDELINES C/S T.002 Issue 5 Revision 1

Image 1 from page 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

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;

Image 1 from page 7

Image 2 from page 7

Image 3 from page 7

Image 4 from page 7

Image 5 from page 7

Image 6 from page 7

Image 7 from page 7

Image 8 from page 7

Image 9 from page 7

Image 10 from page 7

Image 11 from page 7

Image 12 from page 7

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 -

Image 1 from page 8

Image 2 from page 8

Image 3 from page 8

Image 4 from page 8

Image 5 from page 8

Image 6 from page 8

Image 7 from page 8

Image 8 from page 8

Image 9 from page 8

2-1

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.

Image 1 from page 9

Image 2 from page 9

Image 3 from page 9

Image 4 from page 9

Image 5 from page 9

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 -

Image 1 from page 11

Image 2 from page 11

3-1

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.

Image 1 from page 12

Image 2 from page 12

Image 3 from page 12

Image 4 from page 12

Image 5 from page 12

Image 6 from page 12

Image 7 from page 12

Image 8 from page 12

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

Image 1 from page 13

Image 2 from page 13

Image 3 from page 13

Image 4 from page 13

Image 5 from page 13

Image 6 from page 13

Image 7 from page 13

Image 8 from page 13

Image 9 from page 13

Image 10 from page 13

Image 11 from page 13

Image 12 from page 13

Image 13 from page 13

Image 14 from page 13

Image 15 from page 13

Image 16 from page 13

4-1

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

Image 1 from page 14

Image 2 from page 14

Image 3 from page 14

Image 4 from page 14

Image 5 from page 14

Image 6 from page 14

Image 7 from page 14

Image 8 from page 14

Image 9 from page 14

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.

Image 1 from page 15

Image 2 from page 15

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.

Image 1 from page 19

Image 2 from page 19

Image 3 from page 19

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

Image 1 from page 23

Image 2 from page 23

Image 3 from page 23

Image 4 from page 23

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.

Image 1 from page 24

Image 2 from page 24

Image 3 from page 24

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

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

Image 1 from page 26

Image 2 from page 26

Image 3 from page 26

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.

Image 1 from page 27

Image 2 from page 27

Image 3 from page 27

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 LEOLUTs 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 LEOLUTs 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.

Image 1 from page 28

Image 2 from page 28

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 LEOLUTs 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.

Image 1 from page 29

Image 2 from page 29

Image 3 from page 29

Image 4 from page 29

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

Image 1 from page 30

Image 2 from page 30

Image 3 from page 30

Image 4 from page 30

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

Image 1 from page 41

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 -

Image 1 from page 42

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