gr-mcp-docs/reference/cospas-sarsat/r-series/r025.md

title	description	sidebar	documentId	series	seriesName	documentType	isLatest	documentDate	originalTitle
R025: Draft Prelim. Issue A	Official Cospas-Sarsat R-series document R025	badge text variant R note	R025	R	Reports	report	true	October 2025	C/S R.025 - Draft Prelim. Issue A

📋 Document Information

Series: R-Series (Reports) Date: October 2025 Source: Cospas-Sarsat Official Documents

---

COSPAS-SARSAT TWO-WAY COMMUNICATION OPERATIONAL CONCEPT AND HIGH-LEVEL REQUIREMENTS C/S R.025 Draft Preliminary Issue A

C/S R.025 - Preliminary Issue A

COSPAS-SARSAT TWO-WAY COMMUNICATION OPERATIONAL CONCEPT AND HIGH-LEVEL REQUIREMENTS HISTORY Issue Revision Date Comments Preliminary A

Approved by CSC-73

C/S R.025 - Preliminary Issue A

TABLE OF CONTENTS Page History.............................................................................................................................................. i Table of Contents ............................................................................................................................ ii List of Tables ................................................................................................................................ xv List of Figures .............................................................................................................................. xvi 1. INTRODUCTION ....................................................................................................... 1-1 1.1 Overview ..................................................................................................................... 1-1 1.2 Background ................................................................................................................ 1-1 1.3 Objectives ................................................................................................................... 1-2 1.4 Key Stakeholders ....................................................................................................... 1-2 1.5 Reference Documents ................................................................................................ 1-3 1.6 Terms, Abbreviations, and Definitions .................................................................... 1-3 2. TWC OPERATIONAL CONCEPT .......................................................................... 2-1 2.1 Overview ..................................................................................................................... 2-1 2.2 Information Flow ....................................................................................................... 2-2 2.3 TWC-Capable Beacons ............................................................................................. 2-3 2.4 Distress cancellation by TWC .................................................................................. 2-4 3. ROLES AND RESPONSIBILITIES .......................................................................... 3-1 3.1 The Programme ......................................................................................................... 3-1 3.2 TWC Service Provider(s) .......................................................................................... 3-2 3.3 Beacon Manufacturer(s) ........................................................................................... 3-2 3.4 Test Facilities ............................................................................................................. 3-3 3.5 National Administrations.......................................................................................... 3-3 4. GENERAL GUIDELINES TO TWC-SERVICE PROVIDERS, ADMINISTRATIONS AND MANUFACTURERS ................................................. 4-1 4.1 SGB Coding Associated with TWC ......................................................................... 4-1 4.1.1 C/S FLAM with Rotating Field #4 .................................................................... 4-1 4.1.2 Questions, Answers and Instructions ................................................................. 4-4 4.1.3 TWC Database Format Definition ..................................................................... 4-7 4.1.4 Return Link Message for TWC .......................................................................... 4-9 4.1.5 GNSS On-Times .............................................................................................. 4-10 4.2 TWC Considerations for SGB Registries .............................................................. 4-11 4.3 TWC Beacon User Interface .................................................................................. 4-11 4.4 SAR-User Interface ................................................................................................. 4-11

C/S R.025 - Preliminary Issue A

4.5 TWC Beacon Type Approval ................................................................................. 4-12 4.6 TWC Message Dataset Validation ......................................................................... 4-13 4.6.1 TWC message Dataset Validation Principles .................................................. 4-13 4.6.2 TWC message Dataset Validation Process ...................................................... 4-13 4.7 Beacon Design Guidelines ....................................................................................... 4-14 5. TWC IMPLEMENTATION PLAN ........................................................................... 5-1 5.1 Assumptions and Dependencies ............................................................................... 5-1 5.2 Implementation Steps ................................................................................................ 5-2 5.3 TWC Pilot Capability ............................................................................................... 5-2 5.4 Initial Operational Capability (IOC) ....................................................................... 5-3 5.5 Full Operational Capability (FOC) ......................................................................... 5-4 6. TWC HIGH LEVEL REQUIREMENTS ................................................................. 6-1 6.1 Integrity ...................................................................................................................... 6-1 6.2 Availability ................................................................................................................. 6-1 6.3 Latency ....................................................................................................................... 6-1 6.4 TWC Coverage .......................................................................................................... 6-2 6.5 Security ....................................................................................................................... 6-2 6.6 Archiving .................................................................................................................... 6-2

C/S R.025 - Preliminary Issue A

LIST OF FIGURES Figure 4-1: TWC Rotating Field FLAM bit allocation when Answer Format Flag bit is set to 0 (Short Answer) ..................................................................................................... 4-2 Figure 4-2: TWC Rotating Field FLAM bit allocation when Answer Format Flag bit is set to 1 (Long Answer) ..................................................................................................... 4-2 Figure 4-3: Answer Field in the Q/A Slot with up to 15 Possible Answers ................................ 4-6 Figure 4-4: Example Encoding of the User's Choice of Multiple Answers in the Answer Field of the Long Answer Format ...................................................................................... 4-6 [Figure 4-5: CSV Database Format That Might be Used to Host The Different Versions of the Dataset] ................................................................................................................. 4-8 Figure 4-6: RLM Type-3 bit allocation ....................................................................................... 4-9 Figure 4-7: Possible Spectrum of TWC Integration of Functionality into Beacons .................. 4-15 Figure A-1: Summary of the data exchange between SAR authorities and beacon ................... A-1 Figure A-2 - Answers to initial questions ................................................................................... A-2 Figure A-3 - Answers to follow-on questions from SAR Authorities ........................................ A-3 Figure A-4 - Delayed answers from the user .............................................................................. A-4 Figure A-5 - Instructions/information message .......................................................................... A-6 Figure A-6 - User not answering initial questions ...................................................................... A-7 Figure B-7 - Example of the CSV Database Format with a Portion of the Current Database] .. B-2

1-1 C/S R.025 - Preliminary Issue A

INTRODUCTION 1.1 Overview This document outlines the Cospas-Sarsat Programme's operational concept and high-level requirements for Two-Way Communication (TWC). This capability will be an optional Second Generation Beacon (SGB) feature. Due to restrictions on the use of the Cospas-Sarsat assigned 406 MHz frequency band, the Cospas-Sarsat TWC capability will be reserved for use for search and rescue purposes. To enhance the capabilities of the Cospas-Sarsat System, the Programme is planning to introduce a TWC capability which is limited to the exchange of information between the beacon user and SAR authorities. Cospas-Sarsat TWC will be implemented through a collaborative and shared effort among the International Cospas-Sarsat Programme, Two-Way Communication Service Providers (TWC SPs), national authorities and beacon manufacturers. The objective will be to provide Search and Rescue (SAR) authorities with an optional capability to gain additional information about a distress event and provide instructions. This optional capability will be achieved by implementing bi-directional communications between the beacon user and the SAR authorities. Under this optional capability, the SAR authorities will be able to send pre-defined questions and instructions to the beacon user via a TWC-SP. The beacon user will be able to send pre-defined answers to questions to the SAR authorities via a modified 406 forward link alert message (FLAM). 1.2 Background In 2020, following the implementation of the Cospas-Sarsat Type 1 Return Link Service (RLS) capability, the European Commission (EC) proposed an enhancement of the RLS capability to enable information to be passed between SGBs and Rescue Coordination Centres (RCCs). The proposed goal of this optional capability was to enable rescue services to retrieve valuable information from or give instructions to the persons in distress in order to organize and perform the rescue mission in a more efficient and safe manner. At CSC-67 the Council decided "to invite participants to work intersessionally, including in an informal correspondence working group to assess TWC capabilities in the Cospas-Sarsat System". The EC led a Correspondence Working Group on TWC which was held from January to April 2023 resulting in several papers being submitted to JC-37. The submissions revealed that there was not yet agreement on the Programme's high-level strategic vision. As a result, a Plenary splinter group was struck that developed the high-level strategic vision depicted in Figure 2-1 below. The group, with further iteration intersessionally as part of the Correspondence Working Group, generally agreed that:

• There are likely to be multiple TWC-SPs, potentially regionally based, making it essential that the Programme clearly articulate the mechanism and specification that will be common to all TWC-SPs to interface to the Cospas-Sarsat System.

1-2 C/S R.025 - Preliminary Issue A

• The Cospas-Sarsat Programme will be responsible for ensuring that any TWC-SP linked to the Programme meets the Cospas-Sarsat TWC high-level requirements provided in the present document.
• Information presented to the beacon user will be split between an initial automated question set and a follow-on question/instruction set selected by the SAR authority.
• The initial set of pre-defined questions to the beacon user and possible answers provided by the beacon user are a core Cospas-Sarsat capability and will remain the responsibility of the Programme. The answers provided by the beacon users to the initial questions will be automatically sent to SAR authorities.
• The development and management of the SAR TWC Interface (Web Interface or similar method) which supports the follow-on pre-defined questions, possible answers and possible instructions from the SAR authority to the beacon user will be the responsibility of the TWC-SPs. SAR authorities wishing to access this capability will do so through a SAR TWC interface operated by the TWC-SPs. 1.3 Objectives The goal of this document is to guide the implementation of a Cospas-Sarsat-based TWC capability. Given that Cospas-Sarsat supports SAR stakeholders worldwide, the Programme should anticipate the eventual participation of multiple TWC-SPs. In order to ensure interoperability, a common framework and interface between the TWC-SPs and the Cospas-Sarsat System will be essential. This document provides the Cospas-Sarsat TWC framework and outline of the roles and responsibilities of stakeholders. The Programme's objectives in introducing a TWC capability are to: a) Enhance the Cospas-Sarsat Programme's ability to conduct its current mission of providing accurate, timely and reliable distress alert and location data to help SAR authorities assist persons in distress through the addition of an optional two-way communications capability. b) Introduce a capability that is focussed on the needs of SAR authorities while recognizing that the first step in providing that support is to encourage the carriage of a beacon by facilitating the production of a product (beacon) that is appealing to the beacon consumer. c) Introduce an optional message-based TWC capability focused on enhancing the SAR responders' situational awareness. The Programme may consider the introduction of a capability which, subject to technical limitations, could support limited free text messaging in special-use beacons. 1.4 Key Stakeholders The Cospas-Sarsat TWC capability will involve a collaborative effort between:
• The Programme
• TWC Service Providers

1-3 C/S R.025 - Preliminary Issue A

• Beacon Manufacturers
• National Authorities

Response Organizations/SAR Authorities

Beacon Regulatory Authorities For stakeholder roles and responsibilities see section 3. 1.5 Reference Documents a) Cospas-Sarsat Document C/S P.011, "Cospas-Sarsat Programme Management Policy". b) Cospas-Sarsat Document C/S P.016, "Cospas-Sarsat Strategic Plan". c) Cospas-Sarsat Document C/S G.003, "Introduction to the Cospas-Sarsat System". d) Cospas-Sarsat Document C/S G.008, "Operational Requirements for Cospas-Sarsat Second- Generation 406-MHz Beacons". e) Cospas-Sarsat Document C/S S.011, "Cospas-Sarsat Glossary". f) Cospas-Sarsat Document C/S T.018, "Specification for Second-Generation Cospas-Sarsat 406-MHz Distress Beacons". g) Cospas-Sarsat Document C/S T.021, "Second-Generation Cospas-Sarsat 406-MHz Distress Beacons Type Approval Standard". h) Cospas-Sarsat Document C/S A.001, "Cospas-Sarsat Data Distribution Plan (DDP)". i) Cospas-Sarsat Document C/S A.002, "Cospas-Sarsat Mission Control Centres Standard Interface Description (SID)". j) Cospas-Sarsat Document C/S A.005, 'Cospas-Sarsat Mission Control Centre Performance Specification and Design Guidance'. 1.6 Terms, Abbreviations, and Definitions Specific terms, abbreviations, and definitions are included in document C/S S.011.

• END OF SECTION 1 -

2-1 C/S R.025 - Preliminary Issue A

TWC OPERATIONAL CONCEPT 2.1 Overview The Cospas-Sarsat TWC will be an optional capability that will enable beacon users to convey additional information about their situation to SAR authorities and to respond to follow-on questions that SAR authorities may elect to send. The envisioned concept will involve at least two message sets. The first will be a series of pre-defined initial questions and possible answers pre-programmed into the beacon, which will be presented to the beacon operator upon beacon activation. The answers to these questions will be forwarded to the MCC in FLAMs to be processed and sent directly to RCC/SPOCs and the TWC-SP. The Programme, in consultation with SAR authorities and beacon manufacturers, will be responsible for developing and maintaining this message set. The second message set will be a set of pre-defined follow-on messages (e.g., questions, possible responses, instructions, information, etc.) approved and maintained by the Programme but developed by the TWC-SP in coordination with SAR authorities, beacon manufacturers and the Programme. Beacon user responses arising from these follow-on messages will flow through the MCC to the TWC-SP. The TWC-SP will operate the interface between the SAR authorities and the TWC-SP in order to allow SAR authorities to communicate with the beacon user via return link messages (RLM) sent to the beacon using the TWC return link service. Figure 2-1 depicts the conceptual flow of information and division of operational responsibilities.

2-2 C/S R.025 - Preliminary Issue A

Figure 2-1: TWC Conceptual Flow of Information and Division of Responsibilities 2.2 Information Flow Once activated, a beacon will send its initial alert in accordance with current Cospas-Sarsat specifications without delay. The beacon, even if TWC capable, will not wait for additional information from the beacon user. This alert will be processed in accordance with the specifications and procedures applicable for all alerts and, if the beacon is TWC-capable the TWC- SP and the RLSP will be notified. The TWC questions, answers and instructions data will use a new rotating field RF#4 which will alternate with RF#0 (See Document C/S T.018) in the FLAM to transmit TWC information from the beacon to SAR authorities. Upon distress detection and localization by Cospas-Sarsat, the TWC-capable beacon will receive an Acknowledgement RLM (Type 3 acknowledgement) from the TWC-SP via its associated RLSP and will indicate it to the beacon user via an appropriate indicator. If a beacon is TWC-capable, the beacon operator will be presented with a series of initial questions and possible answers pre-programmed into the beacon. The beacon will include these initial answers in the subsequent FLAM bursts, as soon as new information is provided. The beacon information will indicate with which TWC-SP(s) it is associated. The initial FLAM will be forwarded to RCCs/SPOCs in a standard SIT 185 message and include notification that the

2-3 C/S R.025 - Preliminary Issue A

activated device is TWC capable. As soon as available, initial answers will be sent to the RCCs via a standard SIT 185. RCCs may notify SAR responders that the beacon has a TWC capability and of the connection details for the SAR TWC interface. This same SAR TWC interface will provide the initial answers as well. Furthermore, all initial questions and answers and follow-on questions, answers and instructions will be made available by the TWC-SP connected to SAR responders and authorities through a SAR TWC interface. Follow-on TWC messages will flow through the standard Cospas-Sarsat architecture (beacon to satellite to LUT to MCC) and then to the TWC-SP but should not require any manual action by the MCC. If no new information is provided in the allocated TWC bits, these messages should not be forwarded to the RCC. After the beacon location is provided by the Cospas-Sarsat System, the FLAMs received by the MCC shall be forwarded to the TWC-SP in order to keep the complete answers received available to the RCC operator on the SAR TWC interface for a TWC beacon activation. Communication with the beacon through the SAR TWC interface will start with the SAR Authority selecting the activated beacon through the TWC-SP interface and initiating communication with it. Additionally other authorized SAR users may be granted observer rights, allowing them to monitor the communication, without being able to send information to the beacon user. Furthermore, the TWC-SP interface should be designed to prevent any user from restricting access to the system, ensuring that all authorized users, as determined by national authorities, can utilize the interface without interference or obstruction from others. Follow on TWC messages will flow through the standard Cospas-Sarsat architecture (beacon to satellite to LUT to MCC) and then to the TWC-SP, but should not require any manual action by the MCC. Follow-on messages will not flow directly from the MCC to the RCC. Access to the SAR TWC interface shall be restricted and require SAR authorities to register with the TWC-SP in order to access the information. 2.3 TWC-Capable Beacons See documents C/S G.008 for operational requirements and C/S T.018 for technical performance specification details. Second-generation beacons enabled with TWC functionality will: a) receive and extract relevant information from return link messages contained in the RLS signal; b) provide an interface for the beacon user to: i. Read and enter answers to questions presented (e.g., via multiple-choice selections), ii. Read instructions from search and rescue authorities,

2-4 C/S R.025 - Preliminary Issue A

iii. Provide updates on a distress situation, as required by SAR authorities; c) have an embedded database of initial automatic questions and possible answers required by the Cospas-Sarsat Programme that can be updated if a revised set of questions and/or answers are made available; d) upon activation present the initial set of Cospas-Sarsat Programme approved automatic questions and possible answers to the beacon user; and e) have an embedded database of follow-on questions, possible answers and instructions defined by the TWC-SP (in accordance with the validation criteria approved by the Programme) and that can be (optionally) updated if a revised set of questions, possible answers and instructions are made available. The user answers to the initial and follow-on questions are sent to the SAR authorities through the Cospas-Sarsat system and to the TWC-SP. National administrations are requested to provide in document C/S S.007 information regarding the permitted use and coding of beacons with TWC capabilities, including any limitations. Based on the available information in document C/S S.007, manufacturers are required to clearly identify to the user at the time of purchase the geographic or regulatory limitations that may affect the availability of TWC functionality in a beacon with that capability. If the TWC capable beacon supports more than one TWC-SP, the method of selecting the TWC-SP shall be described in the user manual. A TWC capable beacon shall have local access to a dataset of pre-defined initial and follow on questions, possible answers and instructions applicable to each TWC-SP with which it is associated provided by the beacon manufacturer. These may be stored on the beacon, on a related display tool or on a compatible smart device. 2.4 Distress cancellation by TWC The TWC-capable beacon will allow the beacon user to inform the SAR authorities that the alert was a false alert or that the distress situation ceased by prompting the user using the TWC beacon interface, resulting in the activation of the standard SGB cancellation function. If this distress cancellation answer is selected by the beacon user, a confirmation prompt will be displayed and if confirmed, the beacon will automatically initiate the beacon activation cancellation function as per document C/S T.018 section 4.5.7, including the transmission of cancellation messages (Main Field and Rotating Field#15). For the avoidance of doubt, the beacon shall not transmit a response as a TWC message (i.e., not using RF#4). Should the user not confirm the cancellation, the beacon will continue to operate in its normal distress mode, and will redisplay the previous TWC initial question. Once the beacon activation cancellation function has started, the TWC interaction with the beacon user and all further communication ceases.

2-5 C/S R.025 - Preliminary Issue A

The MCC receiving confirming cancellation messages shall also distribute the associated alert message to the TWC SP destination, such that it can adjusts its operations appropriately if the same TWC beacon is subsequently reactivated.

• END OF SECTION 2 -

3-1 C/S R.025 - Preliminary Issue A

ROLES AND RESPONSIBILITIES 3.1 The Programme The Cospas-Sarsat Programme will: a) define the initial questions and possible answers to be encoded into all TWC capable beacons; b) approve a set of validation criteria to ensure the adequacy of follow-on questions, possible answers and instructions that will be offered in library form by TWC-SPs; c) retain the responsibility for ensuring messages are compliant with the authorized use of the 406 MHz Band and therefore will be required to approve these message sets' adequacy according to validation criteria defined in section 4.9 through the Validation Panel process; d) enhance the Cospas-Sarsat system to enable the automatic transmission of a FLAM encoded with initial questions and answers from the TWC capable beacon to the MCC; e) enhance the Cospas-Sarsat system to enable the transmission of the first beacon alert message with TWC information and the subsequent ones if non-redundant from the MCC to the TWC- SP without delay; f) enhance the Cospas-Sarsat system to decode the initial questions and answers from the TWC capable beacon and transmit them to the RCC/SPOC as additional information in the SIT 185 message; g) enhance the Cospas-Sarsat System to enable the transmission of a FLAM encoded with initial questions and answers from the MCC to one or more TWC-SP, as appropriate; h) enhance the Cospas-Sarsat System to enable the transmission of a FLAM from the beacon through the MCC to one or more TWC-SP(s) of messages sent from the TWC-capable beacon containing responses to follow-on questions that may be sent to the beacon user from SAR authorities through the TWC-SP, as well as TWC message reception acknowledgements; i) develop specifications for inclusion in appropriate Cospas-Sarsat documentation to establish type-approval standards for beacons having TWC capabilities; j) in collaboration with TWC Service Providers, define the System-level TWC test scenarios required for the evaluation of the operational distribution of messages by the Cospas-Sarsat Ground Segment from TWC-capable beacons including the prerequisites for their execution; k) consider Beacon Type Approval applications and assign TACs; l) host the TWC message dataset in all its official language translations; m) consider the dataset validation panel's outcome for new dataset release; and n) update the IBRD and/or TAC database to identify TWC beacons, if appropriate.

3-2 C/S R.025 - Preliminary Issue A

3.2 TWC Service Provider(s) The TWC-Service Providers will: a) propose follow-on TWC questions, possible answers and instructions, to be tabulated in library format, in close collaboration with SAR authorities and in consultation with TWC beacon manufacturers and submit to the Programme for review by the Validation Panel; b) establish and operate a message-data processing capability and SAR TWC interface to receive, store and make available to SAR authorities TWC questions, possible answers and instructions to be exchanged with the TWC-capable beacons; c) establish and operate a message-data processing facility to relay follow-on question and instruction messages from SAR authorities to the TWC-capable beacon; d) manage the registration of national SAR authorities and other authorized stakeholders as users of the SAR TWC interface; e) provide materials for the training of the SAR operators intending to utilize the SAR TWC Interface; f) ensure all registered SAR authorities and other properly authorized stakeholders have access to the message-data processing and SAR TWC interface; g) ensure adequate message-data processing and user-interface capacity for simultaneous access to the SAR TWC interface by all relevant stakeholders; h) adhere to Cospas-Sarsat standards, existing and as may be developed, for the initial questions and answers; i) in collaboration with the Cospas-Sarsat Programme, define the system level TWC test scenarios required for the evaluation of the operational distribution of messages by the Cospas- Sarsat Ground Segment for TWC-capable beacons including the prerequisites for their execution; and j) in collaboration with Cospas-Sarsat Programme, implement a new version of the TWC message database when necessary, taking into account the SAR Authorities needs and according to validation criteria approved by the Programme. 3.3 Beacon Manufacturer(s) The Beacon Manufacturer(s) will: a) develop TWC SGB beacons in compliance with applicable C/S specifications and other applicable specifications with an initial focus on PLBs; b) develop and program beacons with the agreed upon initial and follow-on TWC questions and answers and the ability to receive instructions; c) provide a way to update the TWC message database contained in the beacon or associated product(s), if needed; d) define beacon-user interface in coordination with applicable standards bodies; and

3-3 C/S R.025 - Preliminary Issue A

e) support the system level TWC tests conducted by the Programme and the TWC Service Provider with beacon prototypes. 3.4 Test Facilities The Test Facilities will: a) provide a means to perform type approval testing TWC capable beacons according to document C/S T.021 to ensure that they meet the C/S T.018 specifications; and b) develop and implement a test bench capability allowing the testing of the TWC-related capabilities of the TWC-capable beacons submitted by beacon manufacturers for Type Approval Certification. 3.5 National Administrations The National Administrations should consider the following: a) register (i.e., enter into as service agreement) with the TWC Service Provider and determine the permission level (active or monitor only) for national SAR authorities with access to the SAR TWC interface; b) collaborate with the TWC-SP for the definition of the SAR-User Interface requirements. c) establish the national regulations for TWC-capable beacons, as necessary; d) ensure the adequate training of the SAR operators allowed to use the SAR TWC interface; e) limit access to the SAR TWC interface to trained and authorized operators; f) provide an official translation of the TWC message database into any alternative language, if desired, and submit for possible inclusion in the TWC message dataset; g) review and consider updating the national beacon registry to allow the identification of TWC capable beacons; h) update the applicable portion of document C/S S.007 to advise the Programme of the national regulations regarding TWC beacons; and i) update document C/S S.007 to indicate the official translation(s) of the dataset appropriate for potential use in their beacons.

• END OF SECTION 3 -

4-1 C/S R.025 - Preliminary Issue A

GENERAL GUIDELINES TO TWC-SERVICE PROVIDERS, ADMINISTRATIONS AND MANUFACTURERS 4.1 SGB Coding Associated with TWC The following sections present the planned approach for implementing the RLS Type 3 Two-way communication (TWC) messages. Much of the detailed information which follows, can also be found in document C/S T.018 "Specification for Second-Generation Cospas-Sarsat 406-MHz Distress Beacons". If there are any discrepancies between the information included in this document and the information presented in document C/S T.018, the information in document C/S T.018 should take precedence. 4.1.1 C/S FLAM with Rotating Field #4 TWC Rotating Structure and Bit Allocation The following data fields have been identified as being necessary in a RLS Type 3 TWC FLAM (See document C/S T.018 "Specification for Second-Generation Cospas-Sarsat 406-MHz Distress Beacons", Table 3.7 for further details): Rotating Field Element Bit Allocation Rotating Field ID 4 Bits TWC Provider ID 3 Bits TWC message dataset Version ID 5 Bits RLM Type-3 Acknowledgement 1 Bit Answer Format Flag 1 Bit Spare Bit 1 Bit TWC Q/I/A 33 Bits Either Short Answer Format or Long Answer Format Total 48 Bits The new Rotating Field assigned for RLS Type 3 TWC (RF#4) follows the bit allocation illustrated in Figure 4-1 and Figure 4.2. (See document C/S T.018 "Specification for Second-Generation Cospas- Sarsat 406-MHz Distress Beacons", Figures 4-2, and 4-3)

4-2 C/S R.025 - Preliminary Issue A

Figure 4-1: TWC Rotating Field FLAM bit allocation when Answer Format Flag bit is set to 0 (Short Answer) Figure 4-2: TWC Rotating Field FLAM bit allocation when Answer Format Flag bit is set to 1 (Long Answer) This assignment enables having three separate slots of 11 bits each, or one slot of 22 bits followed by one slot of 11 bits, for Questions/Answers or Instructions / Reception Acknowledgements per burst. The short answer format is intended to support only a single answer for a specific question. The long answer format is intended to support selection of multiple answers for a specific question. Both formats can support an instruction(s) with an acknowledgment(s). Questions requiring a long answer format will be flagged in the dataset. Each field of the TWC FLAM structure is described in the following subsections: Rotating Field ID Four bits are allocated to the Rotating Field identifier. For TWC Rotating Field the value is 0100 as defined in document C/S T.018 "Specification for Second-Generation Cospas-Sarsat 406-MHz Distress Beacons", Table 3.7: TWC Rotating Field (#4). TWC Provider ID Three bits have been allocated to identify the TWC service provider or TWC-SP. This allows for a total of eight different service providers, which seems adequate considering that only three potential service providers to date have been identified (i.e., BDS, Galileo, Glonass).

4-3 C/S R.025 - Preliminary Issue A

TWC Message Dataset Version ID The Programme anticipates the need for several versions of the TWC message dataset over the lifetime of the capability. Five bits are allocated for this purpose in order to allow for TWC message dataset updates in case of modifications in the Questions/Answers/Instructions set. This allows for a total of thirty-two different TWC message dataset versions which seems adequate considering that it is unlikely that more than one version per year will be needed. The TWC message dataset will be contained in a single database maintained by the Secretariat in the three official Programme Languages. A complete version history of all approved TWC message dataset versions shall be maintained and shall be made readily available to Programme stakeholders (e.g., MCC, RCCs, National Administrations, etc.), beacon manufacturers and TWC- SPs. Additional languages may be added once Participants provide official translations for inclusion in document C/S [S.TBD]. The mechanism for how the datasets will be provided and controlled is still TBD. The different versions of the dataset shall be available on the Cospas-Sarsat and TWC-SP websites. Updates of the dataset will not be obligatory for the beacon users, and the system must support backward compatibility in the event that a beacon is using an out of date dataset. Beacon manufacturers are expected to load beacons with the most up to date dataset(s) compatible with the appropriate TWC-SP(s) at the time of sale. Additionally, RCCs and MCCs shall be informed of any changes to the Initial questions which should be implemented as a critical change for MCCs. Updates of the versions will be notified by the Secretariat to the beacon manufacturers, the TWC-SPs and the FMCC. The notification of the general public by beacon manufacturers should be left to their discretion. The notification to inform the MCCs of TWC dataset updates should follow a similar process to the TAC notification model with distribution of a narrative SIT 605 message. The notification to inform the RCCs and SPOCs of TWC dataset updates should be carried out with distribution of a narrative SIT [915] message. The Cospas-Sarsat Programme shall make available (e.g., on a server/a website/through an API) all the different versions of the dataset at all times, in a specific format (i.e., CSV file) allowing remote access and download. The MCC shall be capable of updating their locally hosted dataset upon receiving the update notification. In order to avoid a process that could lead to unnecessary latency in the implementation of a new version of the dataset, the update of the locally hosted dataset should not trigger an update of the MCC's software. The MCC should be able to access and use any of the approved dataset versions.

4-4 C/S R.025 - Preliminary Issue A

A dedicated letter to beacon manufacturers at the time of approval of the change shall also be transmitted by the Secretariat. A TWC message dataset version update would be required by the addition, modification, or suppression of a question, answer, or instruction. The initial addition of an alternate language will not require a version update, but substantive changes to a translated message will require a version update. Proposed changes (which are deemed non-urgent) may be collected until a complete revision is made. Any version update shall be validated through a systematic process prior to implementation by the Programme and needs to be approved by the Programme as described in section 4.6. RLM Type 3 Feedback One bit is allocated to acknowledge the reception of the first RLM Type-3 TWC Acknowledgement: when the distress beacon receives the first RLM Type 3 acknowledgement, this bit changes from default value 0 to value 1. Once the TWC link is established, this bit is set according to the behavior specified by the TWC-SP (e.g., for Galileo it stays at the value 1 until either the beacon battery is depleted or the beacon is deactivated whichever comes first). Long/Short Answer Formats This bit defines the way the Rotating Field (#4) data has to be structured. If the bit is set to 0, this means that short-answer-format questions are to be sent, and the bit allocation is the one displayed in Figure 4-1. If the bit is set to 1, this means that a long-answer-format question and answer shall be sent, and the bit allocation is the one displayed in Figure 4-2. Spare Bit One spare bit, currently unused, is available for possible future use. 4.1.2 Questions, Answers and Instructions The main objective of the TWC is to allow the exchange of information between a beacon user in distress and the SAR Authorities in order to support a more informed SAR response. The TWC Questions/Answers/Instructions are broken in two categories:

1. Initial Questions, automatically displayed at beacon activation, for which answers will be directly transmitted to SAR Authorities by MCCs and to the TWC-SP. The aim of the set of initial questions is to report the essential elements of the distress, such as, number of persons involved, nature of the distress and type of assistance required. Every

4-5 C/S R.025 - Preliminary Issue A

question should be relevant in any case of distress without other considerations. This information should help the SAR Authorities to:

• determine the level of distress (assistance / distress / life distress);
• determine which centre is responsible (e.g., land, maritime, aviation, etc.) for the coordination;
• broadcast safety messages and instructions via other means than Cospas-Sarsat;
• determine whether a medical team is required;
• task the first assets.

2. Follow-on Questions/Answers/Instructions, selected by SAR Authorities and sent by the TWC-SPs and for which answers are provided by the beacon user will be sent to the TWC- SP and be available on the SAR TWC interface (web-based or equivalent). The aim of the set of follow-on Questions/Answers/Instructions is to help the SAR Authorities better understand the ongoing event. In order to maximize the benefits of communication between the beacon user and the SAR Authorities, they should cover as many situations as possible. This information should help the SAR Authorities to:

• task specialized teams;
• ensure a good understanding of the situation;
• maintain link with the beacon user;
• provide the beacon user with relevant advice to maximize the success of the operation;
• be aware of any change in the situation. Several scenarios are presented in Annex A. Multiple-Selectable Answers The TWC beacon shall allow the user to select multiple answers for some pre-defined questions. Every question allowing the user to choose multiple answers shall be identified as such in the dataset. For each of these questions that allow multiple-selectable-answers, the long answer format will be utilized in the FLAM. When the Answer format flag bit is set to 1, the long answer format allows for each possible combination of answer(s) (e.g., A1 or A1 + A2 or A2 + A3 + A4) to be identified by a unique bit combination. Consequently, by associating each bit with a single answer, a maximum of 15 answers to choose from is possible and the user can choose any combination of answer options.

4-6 C/S R.025 - Preliminary Issue A

The following details the encoding of the choice of multiple answers in the first Q/A slot in the long answer format. The number of possible answers is 15, meaning that the user will be able to choose among the 15 possibilities, the answers to be sent. Each answer's option is identified with the following nomenclature: Ai for the answer i, with i going from 1 to 15. Each bit is associated with an answer, which means that if a bit is equal to 1 for a particular position it indicates the corresponding Ai, as illustrated in Figure 4-3 below. Figure 4-3: Answer Field in the Q/A Slot with up to 15 Possible Answers If the answers A1, A3, A5, A7, A11 and A13 are the final choice of the user, this results in the answer field being encoded as shown in Figure 4-4. Figure 4-4: Example Encoding of the User's Choice of Multiple Answers in the Answer Field of the Long Answer Format Decision Tree Among the initial automatic questions, some have answers that can trigger a new question. The beacon shall be able to handle a decision tree, meaning that depending on the answer(s) from the beacon user, the beacon shall automatically display the corresponding next question. [The beacon user shall be able to go back to the previous question [in a decision tree] (i.e., back function) and select an alternate response.] [The transmission of intermediate steps in the decision tree shall be delayed for a period of [30 seconds or one minute] to allow the end user to reach the final step before any intermediate steps are transmitted.]

4-7 C/S R.025 - Preliminary Issue A

In the case where the question allows multiple answers that trigger new questions, the different paths of these new questions shall be followed one after the other. Due to the risk of confusing the beacon user and having incoherent paths of questions, special care must be taken when defining the dataset. As with multiple-choice answers, questions for which answers can trigger a subsequent question shall be identified in the dataset. Handling Questions and Answers [TWC beacons shall be capable of allowing the user to backtrack on an answer prior to it being transmitted in case of an incorrect choice and to choose an alternative answer to a question. This capability maybe performed by preferably requiring a confirmation of an answer, where a negative response would automatically take the user back to the start of that question, or by other acceptable means such as a Back Button (Function). Questions so identified in the Q, A & I dataset shall require the beacon user to confirm their selected answer to that question prior to it being transmitted. The end user shall not be able to skip over a question, all Initial questions must be answered in order, however any Follow-on Questions or Instructions take precedence in the question queue over any outstanding Initial questions, which are presented to the end user once they address the Follow-on question or instruction.] 4.1.3 TWC Database Format Definition [The following Figure 4-5 shows the format of the CSV database containing the dataset. It shall include:

• Version ID of the dataset,
• Question ID,
• Language,
• Question Text,
• Answer Format Flag
• Multiple-selectable answers Flag
• Next Question
• Initial Question flag,
• The columns corresponding to each answer option,
• The question ID to which each answer can lead (decision tree questions)] [When the Multiple-selectable answers Flag has a value of 1, the Answer Format Flag shall always have a value of 1, due to the combination of answers being encoded in a Long Answer format RF#4. Moreover, in this case, the beacon shall always display "Select all the answers that apply." in addition of the Question Text.]

4-8 C/S R.025 - Preliminary Issue A

[For the decision tree among the initial questions, if the subsequent question is independent of the beacon user choice of answer(s), the column Next Question shall be filled with the ID of the subsequent question, rather than filling all the "Go to" columns with the same question ID (exception for the Cancellation Protocol). [During the Initial Question phase, when the beacon user skips a question, the next question display will be the one corresponding to the ID in the Next Question column of the skipped question. If there is none, it means that the Initial Question phase is over.]] [Finally, note that the flags can take the value 0 or 1 which shall be interpreted as False and True, respectively.] Version ID Question ID Language Question Text Answer format flag Multiple-selectable answers flag Next Question <5 bits> <7 bits> <1 bit> <1 bit> <7 bits> Initial Question flag

<7 bits>

0001 - Go to 0010 - Go to <7 bits> <7 bits> 0011 - Go to 0100 - Go to 0101 - Go to 0110 - Go to 0111 - Go to <7 bits> <7 bits> <7 bits> <7 bits> <7 bits> 1000 - Go to 1001 - Go to 1010 - Go to 1011 - Go to 1100 - Go to 1101 - Go to <7 bits> <7 bits> <7 bits> <7 bits> <7 bits> <7 bits> 1110 - Go to 1111 - Go to <7 bits> <7 bits> [Figure 4-5: CSV Database Format That Might be Used to Host The Different Versions of the Dataset]

4-9 C/S R.025 - Preliminary Issue A

4.1.4 Return Link Message for TWC The objective of TWC is to provide the SAR Authorities with the information from the beacon user as quickly as possible. In order to do so, the TWC-SP shall use RLM Type 3 which is designed for Two Way Communication, and it shall:

Transmit automatic acknowledgement of the detection and localization (without confirmed position) of the alert by an MCC;

Transmit new follow-on questions or instructions and/or acknowledgement to answers received by the TWC - Service Provider. This RLM Type-3 should not wait for the confirmation of the position but should be sent as soon as a location of the beacon is provided to the MCC. An RLS Type-3 TWC capable beacon may or may not be RLS Type-1 Acknowledgement capable without any impact on the functioning of either. Galileo RLM Implementation Details The following figure illustrates the bit allocation of the RLM Type-3 in the European GNSS (Galileo) Open Service Signal-in-Space Interface Control Document (OS SIS ICD version [TBC]). The following data fields have been identified as being in a RLM Type-3 TWC: SAR RLM Data Values Bit Allocation 15 Hex ID 60 Bits Message Code 4 Bits Acknowledgement 2 Bits Question/Instruction ID 14 Bits (2 slots for Q/I ID) Total 80 Bits Figure 4-6: RLM Type-3 bit allocation Each bit field of the RLM Type-3 TWC structure is described in the following subsections: 15 Hex ID The 15 Hex ID is identical to the 60 bits (15 Hexadecimal characters) of the standard beacon identification of document C/S T.018.

4-10 C/S R.025 - Preliminary Issue A

Message Code In the RLMs, a field of 4 bits are dedicated to describe the RLS service for which the RLM is used. In this case, it is dedicated to TWC. Message code for TWC service is defined as "0011". TWC RLM Function Two bits informs on the function of the RLM Type-3 TWC:

• if the bit values are 00, it means that the information carried by the two Q/I ID slots is new questions or instructions to the beacon. Either the two slots are each filled with a new question or instruction, or only the first slot (Qx/Ix ID) is filled with a new question or instruction and the second slot (Qy/Iy ID) is at default value.
• if the bit values are 01, it means that the information carried by the first Q/I ID slot (Qx/Ix ID) is a new question or instruction to the beacon and the information carried by the second Q/I ID slot (Qy/Iy ID) is an acknowledgement to an answer provided by the beacon user via the question identifier.
• if the bit values are 10, it means that the information carried by the two Q/I ID slots is acknowledgement to the answers provided by the beacon user via the questions identifier. Either the two slots are each filled with an acknowledgement to an answer, or only the first slot (Qx/Ix ID) is filled with an acknowledgement to an answer and the second slot (Qy/Iy ID) is at default value.
• if the bit values are 11, it means that the TWC-SP system is automatically acknowledging that the alert has been detected and at least a location is available (no location confirmation required). Hence, the content of the following two Q/I ID slots is at default value and can be ignored Question/Instruction ID Two slots of seven bits are allocated to the identification of two questions and/or instructions. 4.1.5 GNSS On-Times Currently, the minimum operating times of the GNSS receiver in an RLS capable beacon are that it is on for the first 30 minutes after beacon activation, followed by an on period of 15 minutes every hour for 6 hours as defined by Moffset. For the TWC, the initial on period of the GNSS receiver shall be 180 minutes and after that time the GNSS receiver is on for 15 minutes every hour for 9 hours as defined by Moffset.

4-11 C/S R.025 - Preliminary Issue A

4.2 TWC Considerations for SGB Registries [TBD] 4.3 TWC Beacon User Interface After beacon activation, an indicator should appear in order to notify the beacon user that the TWC link has been established and that the alert has been located. In the initial question-answering phase, the questions are presented sequentially and must be answered before the next question is displayed to the user. Once the user provides an answer, the question-and-answer pair will be encoded by the beacon in the Rotating Field #4 and transmitted. There is no requirement to notify the user that their answer has been received by the TWC-SP or SAR authorities, but this functionality may also be implemented. See document C/S T.018, sections 4.5.17.1 to 4.5.17.4 for details on the TWC Beacon user interface. 4.4 SAR-User Interface The SAR TWC Interface should allow the SAR authority users to:

Display all the communication items (Questions/Answers/Instructions) sorted in chronological order;

Display the links between the questions and the associated answers;

Display the status of the questions and instructions (selected/sent/received by the beacon/answered (for questions only));

[Hand-over the right to another SAR authority to be the active user in the communication with a beacon (only one active user allowed at a time)];

Display to the new user the whole communication that took place between the beacon and previous users;

Display the whole communication in monitoring mode only if an active user is currently communicating with the beacon;

Obtain a copy of past (archived) TWC communications, as allowed under the TWC-SPs policies and user agreements. The SAR TWC Interface should display the communication items (Questions/Answers/Instructions) taking into account the version of the library installed into the beacon.

4-12 C/S R.025 - Preliminary Issue A

4.5 TWC Beacon Type Approval The Programme has responsibility for validating any Cospas-Sarsat specified items as documented (or to be developed for inclusion) in documents C/S T.018 and C/S T.021, consequently, it has the responsibility for type approval of TWC beacons. All TWC features and functionality defined in document C/S T.018 shall be validated by one of the means of compliance defined in document C/S T.021 section 4.4, and the appropriate method of compliance shall be set out in relevant parts of document C/S T.021. Other functionalities related to the TWC that are not specified within the C/S T.018 should be tested and verified by entities outside Cospas-Sarsat as is currently done for beacons with functions under third parties' responsibility (e.g., ETSI, EUROCAE, IEC, RTCA, RTCM, etc.). The development of interface requirements is not an essential function thus it shall be outside of the scope of the Programme unless specified in document C/S T.018. However, testing shall ensure that anything connected to a beacon causes no harm to the beacon or prevents it from fulfilling its primary purpose. The beacons should be updated with the latest version(s) of TWC message dataset when still in production, but the beacon user shall also have the possibility to update it after the beacon has left the manufacturer' facility (e.g., via an external third-party interface). The responsibility to update the dataset in the beacon and/or external user interface is up to the end user with support from the manufacturer as it is outside of the Programme's capability. As part of the type approval process, the beacon manufacturer must include beacon user instructions that demonstrate that the beacon can be updated and how. The TAC approval requirements associated with TWC should include confirmation that: a) The TWC beacon user interface is installed and working (directly through an integrated screen and interface mechanism or indirectly through an external device or some combination with limited functionality on the beacon and additional functionality on the external device). b) Both initial and follow-on questions and answers work correctly. c) The most current dataset(s) of questions, answers and instructions is installed and working with the beacon. d) Dataset version can be updated. e) The beacon properly synchronizes the questions and answers prior to transmission. f) Any additional functionality does not cause the beacon performance to drop below the approved beacon performance requirements. Typical examples of the performance requirements of greatest concern would be "Operational Lifetime" (battery life) and "Frequency Stability" (due to other transmitters such as for external devices). g) All other integral functions of the beacon, including RLS if integrated in the beacon, operate in accordance with Cospas-Sarsat specifications independent of a successful coupling with the TWC interface device.

4-13 C/S R.025 - Preliminary Issue A

4.6 TWC Message Dataset Validation Initial questions and answers, follow on questions and answers, and instructions in all available languages will be contained in document C/S [TBD]. The Programme will be responsible for developing and maintaining the dataset of initial questions, and answers. This will be accomplished through the established Programme management process as outlined in document C/S P.011, "Cospas-Sarsat Programme Management Policy". Proposed changes to initial questions and answers will be reviewed by the Joint Committee and/or an Experts Working Group and recommended to Council for approval. Once approved by the Council, the Secretariat will forward a request for an updated translation to any National Administrations that have provided official translations of the dataset. Once the text in all three official Programme languages is available, the Secretariat will document the official dataset version and all translations in document C/S [TBD], post these updates to the C-S website, and send notification to all TWC- SPs, beacon manufacturers, and the Parties. Additional language translations will be added as they are received and notifications provided. The Programme will exercise oversight over the validation criteria and process for the TWC follow-on questions, answers, and instructions (Q/A/I) dataset validation. 4.6.1 TWC message Dataset Validation Principles The TWC Dataset Validation Panel will ensure that all TWC follow-on Q/A/I messages adhere to the principles outlined below. In addition, the Joint Committee and/or an Experts Working Group will consider these principles when reviewing proposed changes to the initial questions and answers. These principles include that the Q/A/I messages: a) be related to safety of life to align with the Programme's mission; b) use simple phrasing that eases translation among languages; c) allow for efficient exchange of TWC messages between beacon users and first responders; d) not be discriminatory; e) be as short as possible; and f) be direct and affirmative messages. 4.6.2 TWC message Dataset Validation Process The validation of a new release of the follow-on part of the Q/A/I dataset will be performed by a TWC Dataset Validation Panel for the approval by the Parties. The TWC Dataset Validation Panel shall be composed of experts nominated by the Parties and the TWC-SPs and will be supported by the Secretariat.

4-14 C/S R.025 - Preliminary Issue A

The TWC Dataset Validation Panel should be a permanent body, and appropriate amendments to document C/S P.011 should be developed. The complete review process of dataset updates is intended to be an expedited process completed within [TBD] months. The process begins with either Participants (i.e., Parties, user states, ground and space segment providers, per document C/S P.011), observers of the Cospas-Sarsat Programme, or SAR Users submitting a proposal for an update to the dataset to the appropriate TWC-SP. The TWC-SP will consolidate proposed updates as needed, solicit concurrence for the proposed update from their community of SAR Users as appropriate, and forward the mature proposal to the Programme, via the Secretariat, for validation. On receipt of a proposal for an update to the follow-on questions/answers and instructions to a dataset from a TWC-SP, the Secretariat will circulate the proposal to members of the TWC Dataset Validation Panel for review. Once the panel members have confirmed their concurrence with the proposed update, the Secretariat will forward the proposed update to the Party Representatives for approval (typically provided within 14 days). On approval of the update, the Secretariat will advise the TWC-SP that originally consolidated and submitted the updates, as well as all other TWC- SPs, and initiate the processes to update the document C/S [TBD] with dataset in each of the official Programme languages, post it to the Cospas-Sarsat website and inform Participants of the update. Once a new or updated follow-on TWC message dataset has been validated, approved, and documented in document C/S [TBD], the Secretariat will forward a request for an updated translation to any National Administrations that have provided official translations of the dataset. Once these translations are received, the Secretariat will document all translations in document C/S [TBD], post these updates to the Cospas-Sarsat website, and inform Participants of the update. 4.7 Beacon Design Guidelines The beacon design shall adhere to the requirements defined in document C/S T.018 and other international standards, as appropriate. Figure 4-7 provides two examples of the spectrum of methods of implementing a TWC beacon user interface into Second Generation Beacons (other methods of implementation may also be possible).

4-15 C/S R.025 - Preliminary Issue A

User Interface on 3rd Party Device C/S Beacon User Indications Library ID Question & Answer Data Library ID and Q&A Database User I/F App Refinements C/S Beacon User Indications User Interaction Library ID and Q&A Database Question & Answer Data Display System User Controls Library ID and Q&A Database TWC Fully Integrated Into C/S Beacon TWC Minimally Integrated Into C/S Beacon Figure 4-7: Possible Spectrum of TWC Integration of Functionality into Beacons

• END OF SECTION 4 -

5-1 C/S R.025 - Preliminary Issue A

TWC IMPLEMENTATION PLAN To the extent possible, the Programme intends to align the introduction of an optional TWC capability with the introduction into operations of SGBs. The plan described in this section refers to the Galileo RLSP plan for the introduction of SGB TWC capability. Other RLSPs plans might be added to this document in the future. 5.1 Assumptions and Dependencies The successful implementation of the Two-Way Communication (TWC) system in the Cospas- Sarsat Programme hinges on several critical assumptions and dependencies. These are pivotal in guiding the project's direction and ensuring its feasibility and effectiveness.

• Operational Capabilities of Beacons: It is assumed that the beacon user segment will be based on the roll-out of SGB devices and that manufacturers and labs will be capable of respectively producing and testing the optional capability thus producing type approved beacon models.
• Coverage: The TWC functionality, as is any other Cospas-Sarsat function, is intended to be provided globally (and is further described in Section 6.4). However, as TWC is an optional capability, some RCC/SPOCS might choose not to establish interactive communications with compatible users in distress.
• Ground Segment: The TWC will entail changes across key System components (e.g., MEOLUTs and/or MCCs). This plan assumes that such changes will not be major, and will be primarily focussed on the MCCs, but represents an important System evolution introducing the distribution of RLS Type 3 and therefore should be implemented by the ground segment providers in a timely manner (as endorsed by the Council). In addition, a new interface and associated infrastructure, will need to be commissioned and put into operation by the relevant TWC Service Providers (TWC-SP).
• Programme Management: As mentioned above, the rollout of the TWC is heavily dependent on the collaborative efforts of all the involved stakeholders, including beacon manufacturers, the Cospas-Sarsat Secretariat, ground and space segment providers, TWC service providers, national Administrations, as well as SAR operational personnel. Their coordinated efforts are essential to ensuring that the new functionality of TWC conforms to a common architecture, complies with agreed performance standards, and does not harm the current System in operations. In view of this, the plan foresees TWC-focused EWG meetings, as appropriate, to consolidate any intersessional work performed.

5-2 C/S R.025 - Preliminary Issue A

5.2 Implementation Steps The deployment of the TWC is a complex matter requiring the cooperation of multiple stakeholders, and a step-by-step process is the most suitable path for a successful implementation. Therefore, the plan proposed follows a segmented and distinct, well-defined three phases designed for a gradual delivery of TWC added value at each stage, while carefully managing the risks and allowing the multiple stakeholders to progress on their assigned development areas. The three phases consist of: a TWC Pilot Capability, the Initial Operational Capability (IOC) and the Full Operational Capability (FOC). These steps delineate the development and validation, the provision of initial TWC data to SAR providers, and the full compliance to the concept of operations. The necessity, added value (goals), criteria, required changes, and anticipated challenges are further described by phase in the sections below. 5.3 TWC Pilot Capability The TWC Pilot Capability will provide a test environment allowing early access to a subset of the TWC-SP capabilities. Such phase should be used as driving mechanism to develop and test the necessary TWC system integration activities within the Cospas-Sarsat Programme leading to the TWC IOC. Objective: This Phase's main objective is the deployment and validation of an early version of the TWC Service, which will: a) include the development of a test plan for the TWC system which defines success criteria; b) evaluate all aspects of the TWC data flows, and confirm the expected performance levels and support the development, and successful execution, of a system test of the TWC; c) allow SAR authorities to get acclimated to TWC by enabling them to begin preparations for operational deployment; d) establish a feedback loop, capturing operational and system inputs essential for refining the TWC implementation, its operational concept and Service provision; e) engage beacon manufacturers, aiding them on the development and the testing of their respective TWC-capable beacons as well as assisting on the type approval process; f) allow verification of TWC scenarios, analysis of the performance, security and overall effectiveness for SAR operations; g) refine C/S System documents if required by the validation; h) define system testing procedures and success criteria in accordance with the plan developed in a) above; and i) perform System testing and report; the successful outcome for system testing shall be a condition for progressing to the IOC phase.

5-3 C/S R.025 - Preliminary Issue A

Conditions: a) Provision of the required TWC-SP infrastructure including interface to an associated RLSP as shown in Figure 2.1. b) The implementation of the relevant changes by at least the MCC associated with the TWC- SP for the TWC dataflow from MCC to TWC-SP. c) The implementation of relevant changes for the TWC dataflow from at least one MCC to at least one SAR authority. d) The availability of an SGB TWC-enabled prototype beacon but only for the end-to-end demonstration and evaluation. 5.4 Initial Operational Capability (IOC) The IOC phase constitutes the first TWC operational capability implemented by the Programme, which shall include the ability to operationally relay the TWC Q&A data to the relevant SAR authorities and TWC-SP in a limited geographical area and the use of an agreed dataset of questions and answers, based on type-approved beacons. During this phase, provision of the TWC service might be limited geographically to those regions where administrations have committed to making appropriate changes to their ground segment and perform the required actions in order to enable the relevant national SAR authorities to participate in the provision of this service. Initial operational capability is the declaration by the Cospas-Sarsat Programme that the System is capable to provide reliable SGB data and that alert data (including from a TWC beacon) is being distributed operationally between all data distribution regions. IOC is based on a Galileo L-band space segment, a partial TWC capable ground segment, and completion of the TWC Pilot Capability Phase. The MEOSAR SGB system shall provide global alert coverage for the TWC IOC phase. The distribution of TWC messages from the TWC-SP may be limited in geographical area. Criteria for SGB-TWC IOC: a) The MEOSAR SGB System must be at IOC or FOC. b) Operational TWC-SP infrastructure (e.g., SAR User Interface, Interface to MCC Associated with the TWC-SP, RLSP, TWC RLM supported, etc.). c) An approved Q/A/I dataset must be available in at least English. d) The ability to type-approve a TWC-SGB. e) Completion of the approved System Testing for SGB-TWC. f) Regionally available based upon National declaration of TWC processing capability and acceptance of SGB-TWC coding in beacons with country ID (MID) (documented in C/S S.007).

5-4 C/S R.025 - Preliminary Issue A

5.5 Full Operational Capability (FOC) [Full operational capability is the declaration by Cospas-Sarsat that the TWC service should be considered fully operational. At FOC the TWC service satisfies all requirements defined by Cospas-Sarsat and the TWC-SP, including those contained in document C/S A.003. This ensures that sufficient space and ground segment components have been commissioned in accordance with Cospas-Sarsat requirements. The MEOSAR SGB system shall provide global coverage for the FOC phase.] [Criteria for SGB-TWC FOC: a) All IOC criteria is met b) Adopted Q/A/I dataset is available in the 3 Programme languages c) Global SGB coverage with sufficient TWC processing by the Ground Segment for distribution]

• END OF SECTION 5 -

6-1 C/S R.025 - Preliminary Issue A

TWC HIGH LEVEL REQUIREMENTS The objective of this section is to define a minimum standard applicable to all TWC services (all TWC-SPs). The performance of the TWC service is ultimately limited by the performance of the elements of this service, i.e., MEOSAR forward and GNSS return links and the performance of TWC-SP and the TWC SGB. 6.1 Integrity The probability of processing anomalies (i.e., an error in the displayed question/answer/instruction) from a beacon to SAR service shall be less than [10.0^-04] and from SAR service to beacon shall be less than [10.0^-04]. 6.2 Availability The TWC service is considered available when all TWC functions are performed with the defined integrity and within the defined latency performance. The TWC service shall be available [TBD %] of the time (including the Cospas-Sarsat and TWC- SP contributions evaluated at [TBD %] each), over any one-year period. 6.3 Latency The time from selection of answers by the beacon user to the display of these answers on the TWC- SP interface for the SAR authorities shall be shorter than [TBD] minutes [TBD] percent of the time in the first 60 minutes of beacon activation and [TBD] minutes [TBD] percent of the time, thereafter. The time from the transmission of questions/instructions by the SAR authorities on the TWC-SP interface to the display of these questions/instructions on the beacon display shall be shorter than [3] minutes [90] percent of the time assuming the beacon GNSS receiver is active and nominal reception with a clear sky view. Once the first [180] minutes after activation has past, the time from the transmission of questions/instructions by the SAR authorities on the TWC-SP interface to the display of these questions/instructions on the beacon display shall be shorter than [50] minutes [90] percent of the time assuming the beacon GNSS receiver is active for [15] minutes every hour with nominal reception and a clear sky view.

6-2 C/S R.025 - Preliminary Issue A

6.4 TWC Coverage TWC coverage is a characteristic of a service provided by the Cospas-Sarsat Programme and a TWC service provider introduced to ensure that the two way communication between a user with a TWC-capable beacon and SAR personnel is provided at established performance levels in a defined geographic area of the globe. The Cospas-Sarsat Programme intends to provide global 406 MHz forward link alert coverage for SGB TWC capable beacons. The constellation of satellites used by a TWC service provider for the GNSS return link service defines the coverage service region for that TWC SP. It is anticipated that TWC coverage at FOC should be global for each Service Provider. 6.5 Security The SAR TWC Interface service will be limited to registered users. Access will be controlled by user ID and authentication credentials. 6.6 Archiving The TWC service provider should maintain an archive in accordance with local regulatory requirements.

• END OF SECTION 6 -

A-1 C/S R.025 - Preliminary Issue A

ANNEX A - EXCHANGE MESSAGE SCENARIOS [To be updated] [The beacon will exchange information with the SAR authorities via FLAMs (Forward Link Alert Messages) and TWC Type-3 RLMs (Return Link Messages) that will contain the Questions, Answers and Instructions. The Initial Questions are displayed automatically when the beacon is triggered. The follow-on questions are selected by the SAR authorities and sent by the TWC-SP to the beacon via a GNSS signal. Furthermore, beacon and TWC-SP exchange acknowledgements in order to indicate the reception of previous messages. Figure A-1 shows a high-level representation of the operating concept.] Figure A-1: Summary of the data exchange between SAR authorities and beacon [Five distinct user cases are presented and described below:

• The user activates the beacon and answers to the initial questions (see Figure A-2)
• The user answers the follow-on questions asked by SAR authorities (see Figure A-3)
• The user does not immediately answer the follow-on questions (see Figure A-4)
• The user receives information or an instruction message (see Figure A-5)
• The user activates the beacon and does not answer any initial question (see Figure A-6)]

A-2 C/S R.025 - Preliminary Issue A

Figure A-2 - Answers to initial questions [To get an idea of the time scales involved in these scenarios, we can make the following assumptions. The best-case full loop time, with no delays anywhere, is around 2 minutes. However, it is likely that the transmission of an TWC Type-3 RLM and its successful decoding at beacon level will not be immediate, thus a full loop for a given question and answer will probably be of the order of 4 - 5 minutes, and could be more than this, especially after the first 30 minutes of beacon operation. In order to indicate the establishment of the TWC link to the user and to transmit information as soon as possible, no position confirmation is required for the MCC to send data to the TWC-SP or to the SAR Authorities. For all the Figure in this Section, the legend that applies is the following: 1st case (Figure A-1): The user activates the beacon and answers to the initial questions The user triggers its beacon and sends a FLAM containing the information on the TWC capability. The TWC capability triggers the transmission of a TWC Type-3 RLM Acknowledging the alert, without waiting for position confirmations that will be acknowledged by the beacon upon reception, on the next transmitted FLAM.]

A-3 C/S R.025 - Preliminary Issue A

[Meanwhile, the user has the possibility to answer the initial questions. Once the user answers to the first question, the appropriate Rotating Field of the FLAM will be updated with the answered question(s) and their answer(s). Upon reception by the TWC-SP, the SAR Authorities can visualize the answers on the SAR TWC interface or equivalent while receiving the information from the MCC*. The TWC-SP sends to the beacon an acknowledgement of reception of the answers (TWC Type-3 RLM ACK to answer) in the next RLMs via Galileo SIS. The beacon receives the acknowledgement of its initial answers reception by SAR authoritiesand if no more questions or instructions are waiting in the queue, the beacon shall transmit a FLAM with a beacon feedback to the last TWC Type-3 RLM ACK. The FLAM continues through the forward link pipeline and a single alert is transmitted to the TWC-SP. Finally, after this new reception of the FLAM with beacon feedback to the last TWC Type-3 RLM ACK, the TWC-SP acknowledges the reception by the beacon and stops the RLM transmissions.] Figure A-3 - Answers to follow-on questions from SAR Authorities

A-4 C/S R.025 - Preliminary Issue A

[2nd case (Figure A-3): The user answers to follow-on questions from SAR Authorities Following the first case, the SAR Authorities can now select a set of follow-on questions on the SAR TWC interface and generate TWC Type-3 RLM transmission requests via the TWC-SP. The TWC Type-3 RLMs will contain the binary ID of each question. The beacon receives the questions and the user can answer them by choosing among predefined answers. The questions and answers binary IDs are encoded in the RF of the FLAM. Upon reception by the TWC-SP, the SAR Authorities can visualize the answers on the SAR TWC interface. On the TWC-SP side, a reception acknowledgement to the answered questions is sent. At the same time, by the TWC-SP. After that, the TWC-SP stops the repetition of the questions in the TWC Type-3 RLM. The beacon receives the acknowledgement from the TWC-SP and sends a beacon feedback to the TWC Type-3 RLM ACK in a FLAM. Finally, after its journey in the forward link pipeline, the FLAM is received by the TWC-SP that stops the new transmission of TWC Type-3 RLMs upon new reception of a beacon feedback.] Figure A-4 - Delayed answers from the user

A-5 C/S R.025 - Preliminary Issue A

[3rd case (Figure A-4): The user does not immediately answer the questions Similarly, to the second case, the SAR Authorities select a set of questions that are encoded in TWC Type-3 RLMs. The TWC Type-3 RLMs are sent to the beacon via Galileo SIS. If the questions are received and shown at the beacon level but that for any reason the user cannot answer them for the time being the beacon sends the FLAM acknowledging the reception of the questions (beacon feedback to the TWC Type-3 RLM for questions). Upon reception by the TWC- SP, the SAR authorities are notified that the user has received the questions but did not answer them yet. The TWC-SP stops RLM repetitions. When the user eventually answers the questions, the beacon updates the FLAM in order to now include the answers. Upon reception by the TWC-SP, after the forward link pipeline, the SAR authorities can visualize the answers on the SAR TWC interface and the TWC-SP to the answers (TWC Type-3 RLM ACK to answers) sends RLMs containing the reception acknowledgment (TWC RLM ACK). The beacon receives the acknowledgement to the answers (TWC Type-3 RLM ACK to answers) by the TWC-SP and sends its own acknowledgement, beacon feedback to the TWC Type-3 RLM ACK, in the FLAM. Again, after the forward link pipeline, the TWC-SP receives the acknowledgement and stops the TWC Type-3 RLM transmissions.]

A-6 C/S R.025 - Preliminary Issue A

Figure A-5 - Instructions/information message [4th case (Figure A-5): The user receives information or an instruction message In this simpler case, the SAR Authorities want to send instructions or information to the beacon's user. A TWC Type-3 RLM transmission by the TWC-SP is requested with the instruction/information message encoded. The beacon receives the TWC Type-3 RLM with an instruction and sends a FLAM with a beacon feedback to the TWC-Type-3 RLM for the instruction. Upon reception by the TWC-SP, SAR Authorities can visualize the reception acknowledgement (beacon feedback) transferred by the TWC-SP on the SAR TWC interface and the TWC-SP stops the TWC Type-3 RLM transmissions.]

A-7 C/S R.025 - Preliminary Issue A

Figure A-6 - User not answering initial questions [5th case (Figure A-6): The user does not answer initial questions In this scenario, the user triggers its beacon but does not answer the initial questions. The beacon is acting like a non-TWC capable beacon and the SAR authorities still receive the necessary information for the rescue. The FLAM still requests an Type-3 RLM ACK to alert from the TWC-SP. The TWC-SP sends the TWC Type-3 RLM to the beacon in order to acknowledge the alert, without position confirmation. The beacon sends a beacon feedback to the TWC Type-3 RLM ACK to alert the TWC-SP through the forward link pipeline. The TWC-SP stops the transmission of TWC Type-3 RLM ACK to alert.]

• END OF ANNEX A-

B-1 C/S R.025 - Preliminary Issue A

ANNEX B - EXAMPLE OF THE TWC DATABASE [The figure XX below illustrates an example of the database with a portion of the current dataset. The beacon user is first prompted with the question 0000001 "Number of people in distress?" and can choose one of the following answers:

5-8

9-16

17 or more

Cancel Alert If the beacon user chooses one of the first 7 answers [or skips the question], the question corresponding to the ID in the column "Next Question" shall be displayed, which is the question 0000010 "Medicals: Do you need medical Assistance". If the beacon user selects "Cancel alert" then the SGB Cancellation protocol shall be executed by the beacon, without sending RF#4 with the question ID 0000001 and the answer ID 1000 (corresponding to "Cancel Alert"). Another example; if the beacon user is being prompted with the question 0000011 "Nature of distress: What is the nature of distress?" and the user chooses the answer 0001 "Water", the column "0001 - Go to" indicates the subsequent question that shall be immediately displayed to the user, which in this case is 0000100 "Water/Maritime: What is the distress situation?". [If the beacon user skips this question, no other Initial Question shall be displayed as the column "Next Question" is empty, Follow-on Question could be displayed if present in the stack.] Continuing with the question 0000100, the user can choose any combination of answer(s) among the following proposition, as indicated by the "Multiple-selectable answers" flag:

Man overboard

Fire/Explosion

Sinking/Flooding

Piracy/Security threat

Craft disabled

Trapped

I am lost

B-2 C/S R.025 - Preliminary Issue A

The combination of answers will be encoded in the Long format RF#4 as indicated by the "Answer format" flag. Note that if the user chooses several of the 4 answers leading to question 001000 "Number of life rafts in use?", this subsequent question will be displayed only once. [Figure TBS] Figure B-7 - Example of the CSV Database Format with a Portion of the Current Database]

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